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CAPÍTULO 1 


Antes de falar de CDI... 


O assunto principal deste livro é a CDI, mas não iremos começar nossos estudos 
diretamente nela. Ter em mãos uma boa ferramenta é muito bom, porém, antes de 
utilizá-la, precisamos ver sobre desenvolvimento de software como um todo. Mesmo 
que você seja um programador experiente, vale a pena revisitar tópicos importantes 
como esses. Até porque ser experiente não é sinônimo de saber tudo. 

O bom desenvolvimento de software não é uma tarefa trivial. Equilibrar a ba- 
lança que tem, de um lado, a alta coesão, e de outro, o baixo acoplamento é algo que 
se torna mais simples com a experiência e observando bons códigos. 

Não é possível justificar a má qualidade de um software pela quantidade de mu- 
danças que o mesmo precisou sofrer por alterações no negócio, ou simplesmente 
por mudança de opinião do cliente. Isso vai acontecer, e cabe a nós, desenvolvedo- 
res, projetarmos nossas aplicações de forma a acomodar da melhor forma possível 
essas mudanças. 

A menos que o software que estivermos desenvolvendo seja algo para uma ne- 
cessidade temporária, e não tenha um uso permanente, certamente ele mudará, e 
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não apenas uma vez, e com isso algumas partes dele irão sofrer com essa mudança. 
Pode ser até que, dependendo da urgência, a parte afetada pela mudança precise ser 
melhorada depois, mas não podemos deixar que esse efeito seja propagado para toda 
a aplicação. 

Tomemos como exemplo uma aplicação que controle tudo relacionado aos re- 
cursos humanos de uma empresa, desde o cadastro detalhado dos dados dos funcio- 
nários até a folha de pagamento. Agora vamos considerar uma mudança de legislação 
que nos obrigue a mudar a forma como a folha de pagamento é calculada, e essa seja 
simplesmente a parte mais complexa de todo o sistema, uma vez que além do salário 
de cada funcionário, é preciso também calcular todos os impostos e descontos de 
plano de saúde, empréstimos com desconto em folha e tudo mais. 

Nesse cenário, é possível argumentar que a mudança é inviável por mexer no 
cerne do sistema? Obviamente, não. Então nosso sistema precisa ser resiliente, ou 
seja, suportar bem as mudanças. 

No cenário apresentado, a mudança de todo o cálculo da folha de pagamento 
provavelmente não será a pior parte do trabalho. Geralmente a equipe sabe progra- 
mar, escrever código, e consequentemente vai saber passar para a IDE as alterações 
na legislação. A pior parte costuma ser o reflexo dessa mudança no restante do soft- 
ware. Apesar de não ser o foco do livro, veremos um pouco sobre testes no capítulo 
10, e então entenderemos o quanto essa é uma ferramenta importante para minimi- 
zar os riscos desses comportamentos não previstos após uma alterações. Mas antes 
mesmo de escrever testes para o sistema, temos que projetar esse sistema de forma a 
não propagarmos as mudanças de uma determinada parte para o sistema todo. Esse 
efeito cascata é que costuma ser a pior parte de uma mudança grande. 


1.1 BOAS PRÁTICAS DE ORIENTAÇÃO A OBJETOS 


A baixa coesão e o alto acoplamento são as principais causas de uma mudança, que 
deveria ficar retida em uma parte, sair destruindo o sistema todo. Mas o que real- 
mente é isso? Ouvimos tanto falar em coesão e acoplamento mas as vezes não temos 
certeza do que isso significa. 


Coesão 


A coesão é a capacidade de um objeto estar focado na sua tarefa específica. Se seu 
papel é calcular o salário do funcionário, então que faça isso. Ele não deve calcular 
o salário e calcular o desconto do imposto de renda, e calcular o desconto do plano 
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de saúde, e calcular as férias proporcionais daquele mês, e mais um monte de coisas. 
Isso porque se uma dessas coisas mudar, nosso código muda. 

Não existe porém uma regra que determina até que ponto algo deve estar junto, 
ea partir desse ponto as coisas devem ser separadas. No exemplo anterior, podemos 
ter tudo isso num mesmo objeto se julgarmos o melhor local, mas seria interessante 
termos métodos específicos separando cada tarefa, ainda que sejam privados, e de- 
pois ter um método que combine todos esses subcálculos. 

Podemos perceber que, dessa maneira, criamos níveis de retenção da mudança. 
Se o cálculo de imposto de renda mudar, mudamos apenas o método específico e 
os demais não são afetados. Se todo o cálculo da folha de pagamento mudar, talvez 
tenhamos que alterar a classe toda, mas essa mudança ainda ficaria restrita a essa 
classe, não afetando as demais do sistema. 


Granularidade 


E quanto ao fato de deixarmos os subcálculos em métodos específicos dentro 
de uma mesma classe, não seria mais adequado colocarmos cada um deles em uma 
classe diferente? Sem fazer isso não estaríamos criando uma classe pouco coesa, que 
faz coisas demais? 

Novamente, não existe uma resposta para qualquer cenário. Essa medida de ta- 
manho de cada unidade, como método, classe, subsistema, chamamos de granu- 
laridade. Se tivermos classes menores, cada uma contendo um subcálculo desses, 
podemos dizer que estamos trabalhando com uma granularidade mais fina. É só 
imaginar cada classe como um grão de areia. Nesse caso teríamos uma areia bem 
fina. 

Agora se fizermos cada parte do cálculo maior em um método diferente, mas 
na mesma classe, e formos aplicando a mesma ideia em todo nosso sistema, nossas 
classes serão como grãos maiores de areia — logo teremos uma granularidade mais 
grossa. 

E qual o tamanho ideal? A partir de qual momento precisamos transformar par- 
tes do nosso método em métodos separados, e depois separar esses métodos em clas- 
ses específicas? Como não há resposta mágica, costumamos deixar nosso método no 
tamanho máximo de uma tela de um monitor médio. Então, se formos analisar o có- 
digo de um método, podemos fazê-lo sem rolar a imagem no monitor. Mas note que 
consideramos um monitor médio, pois de nada adianta você ter um monitor de 30” 
com uma resolução absurda enquanto os outros membros da equipe têm monito- 
res de 17” ou 19” com uma resolução bem menor. E pense, ainda que todos tenham 
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essa tela enorme, será que para enchê-la toda com código, não teremos informação 
demais para analisar? A analogia do método do tamanho de uma tela é para ajudar 
que ele seja pequeno, de fácil compreensão. Você tem que olhar e logo entender. Se 
a tela for muito grande e a fonte muito pequena você pode conseguir colocar uma 
bíblia inteira nela sem precisar utilizar a rolagem, mas isso não vai ajudar muito. 

De forma semelhante, devemos cuidar do tamanho das nossas classes. Não há 
uma regra baseada na quantidade de métodos, pois o tamanho deles pode variar 
bastante. Podemos ter métodos com meia dúzia de linhas e outros do tamanho da 
nossa tela. Mas é interessante definir uma meta comum para a toda a equipe, ou para 
você, caso trabalhe sozinho. Defina por exemplo 150 ou 200 linhas e veja se funciona 
bem. Utilize ferramentas na IDE ou no servidor de integração contínua que faça 
relatórios automáticos de quais classes ou métodos estão muito grandes, isso vai te 
ajudar no começo, mas lembre-se que o mais importante é gerenciarmos o significa 
dos métodos e das classes. Você não vai quebrar um método ou classe porque uma 
ferramenta está mandando, você vai usar esse indicador como um alerta te avisando 
que o método ou classe está grande demais, e então você vai readequá-los para que 
se mantenham sempre simples de entender e fáceis de alterar, pois mudanças sempre 
existirão. 
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OUTROS CENÁRIOS ONDE AVALIAMOS A GRANULARIDADE 


Esse conceito de granularidade é importante também em outros ce- 
nários, como na programação distribuída. Na programação local (não 
envolvendo passagem de valores pela rede) podemos chamar diversos 
métodos, cada uma realizando uma pequena parte do trabalho e jun- 
tando o resultado em milissegundos. Quando fazemos uma programa- 
ção distribuída, chamando um método que está rodando em outra má- 
quina, precisamos que esse método faça mais coisas, para precisarmos 
chamar menos métodos diferentes para obter o mesmo resultado, pois 
cada invocação de método diferente passa pela rede para chegar ao ou- 
tro computador, então é melhor um número menor de invocações. 

Nesse caso da programação local versus a programação distribuída, 
quando os método nos dão respostas menores, temos uma granularidade 
mais fina, e quando as respostas são mais completas, temos uma granu- 
laridade mais grossa. Qual a melhor? Geralmente quando programamos 
local, uma granularidade mais fina nos dará métodos menores, e conse- 
quentemente mais fáceis de entender. Já quando temos uma chamada de 
método remota, é melhor uma granularidade mais grossa, pois temos a 
latência de rede no meio do caminho. Mesmo nesse tipo de programa- 
ção, devemos ter a separação de cada parte do trabalho feita da mesma 
maneira que faríamos na programação local, facilitando o entendimento 
do código. A diferença é que não chamaremos cada um desses métodos, 


e sim um método que combine todos eles. 











Acoplamento 


Enquanto a coesão é a medida do quanto um objeto é focado em sua tarefa, o 
acoplamento é a medida da sociabilidade desse objeto, ou o quanto ele se relaciona 
com os outros objetos e a força desses relacionamentos. Por exemplo, receber um 
objeto do tipo Funcionario como parâmetro de um método é um acoplamento 
menor que ter dentro da nossa classe uma propriedade desse tipo, que por sua vez é 
menor também do que nossa classe ser um subtipo de Funcionario. 
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Dependência Composição Herança 
| public class Classe ( public class Classe 
public void metodo(Funcionario) ( extends Funcionario ( 
< private Funcionario funcionario; < 


} } 


Figura 1.1: Ilustração referente ao acoplamento, quando menor, melhor 


Coesão e acoplamento são lados opostos de uma balança. À medida que pro- 
curamos manter uma alta coesão, deixaremos de ter classes “sabe-tudo” e teremos 
mais relacionamentos entre classes com papéis específicos. Mas se tentarmos dimi- 
nuir demais o acoplamento, voltaremos a ter classes que agregam muitas funções, 
visando diminuir as dependências entre elas, mas acabando com sua coesão. 

Para nossa sorte, essa equação já vem sendo resolvida há bastante tempo, e a 
forma como isso tem sido feito é focar na coesão, e delimitar bem as fronteiras en- 
tre as classes para que suas inter-relações não causem um acoplamento negativo. 
Um acoplamento negativo é aquele em que as classes que se relacionam conhecem 
demais o trabalho da outra. Assim, por mais que as responsabilidades estejam (par- 
cialmente) separadas, a classe A sabe como a classe B está implementada e toma 
diversas decisões levando isso em consideração. Na prática, a implementação de 
uma é continuação da outra. 

Ao definir fronteiras entre as classes, devemos cuidar para que uma funcione de 
forma totalmente independente da outra. Por mais que a mesma pessoa codifique 
ambas, é importante que as decisões internas de uma não se propagem para a outra. 
Assim, se uma mudar, a outra pode continuar igual. 

Por exemplo, vamos considerar uma classe que calcula toda a folha de pagamento 
de uma empresa, e outra classe que exibe os dez maiores salários para o presidente da 
empresa. Imagine que, ao calcular a folha de pagamento, a primeira classe armazena 
uma lista dos funcionários que tiveram seus salários calculados em ordem decres- 
cente de salário. E a segunda classe simplesmente exibe os primeiros dez elementos 
dessa lista, pois sabe que após o cálculo a lista estará ordenada. 


Ocorre porém que, por questões de performance, a primeira classe é alterada, de 
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modo a realizar o cálculo dos salários de forma paralela, e após a junção do trabalho 
de cada Thread resultado não está mais ordenado. Nesse caso, a classe que exibe os 
dez maiores salários sofrerá um impacto por estar acoplada demais com a primeira. 
Esse tipo de acoplamento é um que devemos evitar. 

Defina interfaces claras entre as classes, deixando nítido o que cada uma recebe e 
devolve de informações para a outra, e implemente cada classe de forma que somente 
a interface da outra seja conhecida, e sua implementação interna seja totalmente 
ignorada. 


1.2 LIDANDO COM O ACOPLAMENTO 


Como dito anteriormente, lidar de forma eficiente com acoplamento é uma matéria 
que vem sendo aprimorada há muitos anos. Existem diversos padrões de projeto 
que nos ajudam a gerenciá-lo de forma eficiente, e também ferramentas — ou fra- 
meworks — que nos ajudam a implementar esses padrões de uma maneira simples. 

Esse não é um livro de padrões de projetos, mas veremos alguns para nos ajudar 
a entender na prática esses conceitos. Um padrão fácil de entender e que servirá para 
nosso exemplo inicial é o Strategy. Imagine, por exemplo, que precisamos compactar 
um arquivo, que será representado por um array de bytes. Precisamos de uma classe 
que receba esse array e devolva um novo array que represente o arquivo já compac- 
tado, porém temos diferentes formas, ou estratégias de compactação, como o zip, o 
rar e o bzip2. O interessante desse padrão é que podemos facilmente trocar a es- 
tratégia, ou algoritmo utilizado para resolver o mesmo problema, sem alterar nosso 
código para isso. 

Trazendo para um exemplo mais próximo da nossa realidade, vamos considerar 
o nosso cálculo de salários. Podemos ter diferentes implementações de uma calcula- 
dora de salário no nosso sistema, uma para cada versão do plano de cargos e salários 
da empresa. Provavelmente nesse caso não teremos essas diferentes versões execu- 
tando em um mesmo momento, já apenas um plano de cargos fica em vigor por vez. 
Mesmo assim aplicaremos o mesmo conceito pois a interface continuará a mesma, e 
apenas a implementação será alterada. 

Para exemplificar vamos considerar a interface a seguir. 


public interface CalculadoraDeSalarios { 


double calculaSalario(Funcionario funcionario); 
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E vamos considerar que no ano 2000, a empresa possuía um salário único para 
os funcionários, todos recebiam R$ 2.000,00. 


public class CalculadoraDeSalariosPadrao 
implements CalculadoraDeSalarios { 


public double calculaSalario(Funcionario funcionario) { 
return 2000.0; 


Jáiniciamos bem, utilizando uma interface que define o que se espera de uma cal- 
culadora de salários, mas mesmo assim precisaremos instanciar um objeto da nossa 
classe quando formos utilizar a calculadora. Logo, teríamos um trecho de código 
parecido com o seguinte. 


Funcionario funcionario = buscaAlgumFuncionarioDeAlgumLugar (); 
CalculadoraDeSalarios calculadora = new CalculadoraDeSalariosPadrao(); 
double salario = calculadora.calculaSalario(funcionario); 


Toda vez que precisássemos de uma instância da CalculadoraDeSalarios 
seria necessário usar o operador new e criar uma nova instância da implementação 
que temos. Mas, por mais que a interface facilite bastante na evolução do sistema, 
permitindo-nos trocar a implementação sem quebrar os clientes, quando mudarmos 
essa implementação, precisaremos alterar todo nosso sistema, buscando onde a im- 
plementação antiga estava sendo usada e trocar pela nova. Essa nova implementação 
pode ser, por exemplo, com base em um novo plano de cargos e salários e tenha saído 
em 2002. 


public class CalculadoraDeSalariosPlano2002 
implements CalculadoraDeSalariost 


public double calculaSalario(Funcionario funcionario) { 
if (funcionario.getEscolaridade() == Escolaridade.SUPERIOR)( 
return 3000.0; 


} 
else{ 

return 2000.0; 
} 
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Com base no novo plano, funcionários com nível superior passam a ganhar R$ 
3.000,00, enquanto os demais continuam ganhando R$ 2.000,00. Não se preocupe 
com a implementação, ela está propositalmente simples, a ideia é percebermos o 
problema que teremos, pois precisaremos fazer um find replace na nossa aplicação 
trocando todos os lugares onde a implementação antiga era usada. 

Por esse problema, geralmente aliado ao padrão Strategy, costumamos uti- 
lizar o padrão Factory Method. Assim temos um método que sabe criar ob- 
jetos da forma correta. No nosso caso, esse objeto é a implementação de 
CalculadoraDeSalarios. A nossa implementação desse método construtor de 
objetos pode ser algo bem simples como o que segue. 


public class CalculadoraDeSalariosFactory { 
public CalculadoraDeSalarios criaCalculadora()f 
return new CalculadoraDeSalariosPlano2002() ; 


E seu uso ficaria da seguinte forma. 


Funcionario funcionario = buscaAlgumFuncionarioDeAlgumLugar (); 
CalculadoraDeSalariosFactory factory = 

new CalculadoraDeSalariosFactory(); 
CalculadoraDeSalarios calculadora = factory.criaCalculadora(); 
double salario = calculadora.calculaSalario (funcionario); 


A vantagem de termos um meio “terceirizado” de criar nossos objetos, 
é que qualquer mudança na forma de criá-los fica escondida dentro dele. 
Até agora, a mudança que tivemos foi apenas trocar a implementação da 
CalculadoraDeSalarios, mas a alteração poderia ser maior. 

Apenas para evoluir nessa linha de raciocínio, consideremos que, mesmo após a 
reestruturação do plano de cargos da empresa, em 2002, os funcionários reivindica- 
ram que fosse seguido o piso salarial da categoria, e que essa solicitação foi atendida. 
Logo, como desenvolvedores do sistema que calcula a folha de pagamento, precisa- 
remos utilizar essa referência salarial para calcular os salários, e para tal, definimos 
a seguinte interface. 
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public interface TabelaDeReferenciaSalarial { 
double buscaPisoSalarial(Cargo cargo); 


Assim, teremos que garantir que o salário do funcionário nunca seja menor que o 
piso do cargo que ele ocupa. Como esse é um exemplo apenas didático, que nem fará 
parte do projeto que desenvolveremos, vamos ignorar sua implementação, conside- 
rando apenas que ela se chama TabelaDeReferenciaSalarialPadrao. Agora 
precisamos apenas passar essa tabela para nossa CalculadoraDeSalarios. 
Para que essa dependência fique mais explícita podemos definir um método 








setTabelaDeReferenciaSalarial na interface CalculadoraDeSalarios. 
Dessa forma, quem implementar essa interface saberá que obrigatoriamente precisa 
receber essa tabela. 


public interface CalculadoraDeSalarios { 


double calculaSalario(Funcionario funcionario); 
void setTabelaDeReferenciaSalarial( 
TabelaDeReferenciaSalarial tabela); 


} 


public class CalculadoraDeSalariosFactory { 
public CalculadoraDeSalarios criaCalculadora(){ 
TabelaDeReferenciaSalarial pisosSalariais = 
new TabelaDeReferenciaSalarialPadrao(); 


CalculadoraDeSalarios calculadora = 
new CalculadoraDeSalariosPlano2002(); 


calculadora. setTabelaDeReferenciaSalarial (pisosSalariais); 
return calculadora; 


Veja que interessante, dessa vez não trocamos a implementação da 
CalculadoraDeSalarios, mas mudamos a forma como ela é construída. 
Ainda assim não precisamos sair alterando nosso código em todo lugar, e isso é 
muito bom. Contudo, quase sempre há espaço para melhorias. 


10 
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1.3 EVOLUÇÃO DAS FERRAMENTAS DE GESTÃO DE DEPEN- 
DÊNCIA 


Apesar de muito simples, o que fizemos com nossa factory foi uma forma de ge- 
renciar as dependências da nossa aplicação, especificamente as implementações de 
CalculadoraDeSalarios e TabelaDeReferenciaSalarial, esta última é 
uma dependência indireta da nossa aplicação, pois quem depende dela é a calcu- 
ladora. 

O trabalho está indo bem, mas nosso objetivo é conseguir trocar essas dependên- 
cias sem precisar alterar nossa aplicação, nem que essa alteração esteja restrita a uma 
única classe. Em outras palavras, veremos o que será preciso fazer para trocarmos os 
componentes (dependências) da nossa aplicação sem a necessidade de recompilação 
alguma. 

Para exemplificar, imagine que depois de muitos anos do sistema em execução, 
o sindicato disponibiliza um webservice com as referências salariais, e você crie uma 
nova implementação da TabelaDeReferenciaSalarial com base nesse serviço 
web. Com as alterações que faremos a partir de agora, será possível colocar um novo 
jar com a implementação nova no classpath da aplicação, alterar um arquivo de con- 
figuração (ou as vezes nem isso), e ao reiniciar a aplicação a nova implementação já 
está em uso. 

Já foi falado que existem frameworks que nos ajudam nesse trabalho, e veremos 
os principais precursores da CDI nas seções a seguir; mas antes disso veremos como 
fazer essa gestão manualmente. 


1.4 O BOM E VELHO ARQUIVO PROPERTIES 


A forma mais simples de tirarmos a instanciação das dependências de dentro do có- 
digo, é usando arquivo de propriedades, no formato chave=valor. Para trabalhar com 





esses arquivos, usaremos a classe java .util.ResourceBundle. Sua utilização é 
bem simples, e veremos melhor através de um exemplo. 

Primeiro precisaremos criar um arquivo na raiz do classpath da nossa aplicação. 
Para isso, coloque o arquivo na pasta src do seu projeto do eclipse, ou src/java 
se estiver utilizando o netbeans. Esses são os diretórios padrões, mas você pode 
especificar outro diretório dentro da IDE. O importante é que o arquivo com nome 
dependencias.properties fique no pacote default. 

Após criar esse arquivo, que é um arquivo texto simples, vamos deixá-lo com o 
seguinte conteúdo. 
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CalculadoraDeSalarios br.com...CalculadoraDeSalariosPlano2002 
TabelaDeReferenciaSalarial br.com...TabelaDeReferenciaSalarialPadrao 


O divisor entre a chave e o valor pode ser um = ou simplesmente um espaço em 
branco, que foi o utilizado. E como vamos instanciar essas classes de forma dinâmica, 
é importante colocarmos o nome completo da classe, que inclui o pacote. No trecho 
de exemplo os nomes foram encurtados para ser mais facilmente visualizado. 

A seguir o trecho que cria a instância da classe a partir da leitura de seu nome 
nesse arquivo properties. 


public class CalculadoraDeSalariosFactory { 


private ResourceBundle bundle = 
ResourceBundle.getBundle ("dependencias"); 


public CalculadoraDeSalarios criaCalculadora()f 
String nomeDallasse = 
bundle.getString("calculadora de salarios"); 

try { 
Class<?> classe = Class.forName (nomeDaClasse); 
return classe.asSubclass (CalculadoraDeSalarios.class) 

.newInstance(); 

} catch (Exception e) { 

return null; 





Como podemos ver, obtemos uma instância de ResourceBundle através do 
método getBundle, que recebe como parâmetro o nome do arquivo properties que 
criamos, sem a extensão .properties. Com esse objeto em mãos, conseguimos 
recuperar qualquer valor de dentro do arquivo passando sua respectiva chave para 
o método get String. Por fim, dentro de um try/catch, fizemos a instanciação 
da classe a partir de seu nome, e depois a instanciação do objeto a partir da instância 
da classe. O método asSubclass está sendo usado apenas para retornarmos o tipo 
correto da classe, caso contrário o método newInstance devolveria um Object 
em vez do tipo que esperamos, e então teríamos que fazer um cast. 

O uso do try/catch é obrigatório pois estamos lidando com nome de classes 
que podem estar digitados incorretamente por exemplo, ou a classe pode não ter ser 
visível ou não ter um construtor padrão visível. 
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Esse trecho serviu para entendermos como instanciar um objeto a par- 
tir de um arquivo properties, mas agora precisamos terminar de criar nossa 
CalculadoraDeSalarios de forma correta, pois ainda falta instanciarmos a 
TabelaDeReferenciaSalarial. Para que o código não fique muito repetitivo, 
vamos criar um método privado chamado criaInstancia. Esse será um método 
genérico nos dois sentidos da palavra, pois usa generics e serve para qualquer tipo de 
classe. 


private <T> T criaInstancia(Class<T> classe){ 
String nomeDaClasse = bundle.getString(classe.getSimpleName()); 
try { 
Class<?> clazz = Class.forName (nomeDaClasse); 
return clazz.asSubclass(classe) .newInstance(); 
} catch (Exception e) 1 
return null; 


Tanto nesse código, quanto no anterior, o ideal é que usemos uma API de Logger 
para registrar um possível erro nesse processo, e não apenas devolver null sem 
sabermos o real motivo de isso ter ocorrido. 

Analisando esse código, percebemos que utilizamos o nome simples da classe 
como chave a ser buscada no dependencias. properties. Isso deu certo porque 
utilizamos o mesmo nome da interface que desejamos instanciar como chave dentro 
do arquivo, o que facilitou nosso trabalho agora. O restante do código é praticamente 
o mesmo que vimos anteriormente. 

Agora que já temos uma estrutura para instanciar nossos objetos, podemos voltar 
ao método criaCalculadora da nossa factory, que é o que realmente devolve a 
dependência que precisamos. 


public CalculadoraDeSalarios criaCalculadora()f 
TabelaDeReferenciaSalarial pisosSalariais = 
criaInstancia(TabelaDeReferenciaSalarial.class); 


CalculadoraDeSalarios calculadora = 
criaInstancia(CalculadoraDeSalarios.class); 


calculadora. setTabelaDeReferenciaSalarial (pisosSalariais); 
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return calculadora; 


Uma vez que criamos o método genérico criaInstancia, ficou bem sim- 
ples criar instâncias de qualquer classe. Em um sistema real, esse método prova- 
velmente ficaria em uma classe utilitária que seria utilizada por qualquer factory, 
ou ainda evoluiríamos mais esse método para que pudéssemos ter um factory com- 
pletamente genérica, que utilizasse reflection para buscar subdependências como a 
TabelaDeReferenciaSalarial dentro da nossa CalculadoraDeSalarios. 

Outra opção seria também trocar os arquivos de propriedades por registro em 
banco de dados. Nesse caso, se as classes já estivessem no classpath da aplicação, não 
seria necessário nem mesmo reiniciá-la para trocarmos a implementação de uma 
interface. Porém, independentemente de como continuaríamos o desenvolvimento 
da nossa aplicação, já vimos o que seria necessário para gerenciarmos manualmente 
a implementação das dependências das nossas classes. Agora passaremos a ver como 
podemos fazer essa gestão através de frameworks. 


1.5 BUSCANDO AS DEPENDÊNCIAS COM SPRING E XML 


O Spring é um framework muito importante para a história do Java, pois enquanto 
o JEE do passado, chamado à época de J2EE, era muito verboso no seu uso, o Spring 
facilitou bastante as coisas, dando uma alternativa por fora da “linha oficial” do Java. 
Seria como comprar um carro mas ir a uma boa oficina não oficial, pois a oficial 
era demasiadamente burocrática e levávamos muito tempo para conseguir agendar 
uma revisão. Se analisarmos os códigos feitos até alguns anos usando Spring ve- 
remos muitos aquivos XML, o que acabou inclusive na época caracterizando pejo- 
rativamente o framework, e até certo ponto a própria plataforma Java como sendo 
orientada a arquivos XML. 

Nessa seção, estaremos vendo o Spring do ponto de vista histórico, então, por 
mais que hoje seja possível utilizar anotações em sua configuração, no momento 
histórico em que ele foi mais importante a configuração era basicamente por XML. 
Porém se formos iniciar um projeto utilizando Spring hoje em dia, certamente não 
faríamos como veremos a seguir. 

Outro ponto importante de considerarmos é que estaremos interagindo com a 
API do Spring de uma forma desanexada de seu contexto. Estaremos basicamente 
utilizando o Spring como factory. Faremos isso apenas para simplificar o entendi- 
mento, e não visando comparações com Seam ou CDI. Quando digo fora do contexto 
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significa que partiremos de uma classe simples, ou até mesmo um método main, e 
então chamaremos o primeiro bean através do contexto do Spring. 

Para continuar na mesma linha do exemplo anterior, vamos considerar a mesma 
factory que cria CalculadoraDeSalarios. Porém agora iremos implementá-la 
usando Spring. 


import org.springframework.context. ApplicationContext; 
import 
org.springframework.context.support.ClassPathXmlApplicationContext; 


public class CalculadoraDeSalariosFactory { 


private ApplicationContext context = 
new ClassPathXmlApplicationContext ("dependencias.xml"); 


public CalculadoraDeSalarios criaCalculadora()f 
CalculadoraDeSalarios calculadora = 
(CalculadoraDeSalarios) context.getBean("calculadora"); 


return calculadora; 


Não veremos aqui como configurar um ambiente para executar o Spring, mas na 
documentação do framework é possível ver os jars necessários para sua utilização. 
O que nos importa é a instanciação do seu contexto e a obtenção de um objeto de 
dentro dele através do método get Bean. Esse contexto foi criado tendo como base 
o arquivo dependencias .xml, que geralmente é deixado na raiz do classpath da 
aplicação, assim como fizemos com o arquivo properties. 

Pode não parecer, mas nossa factory está pronta. Não precisamos instanciar a 
TabelaDeReferenciaSalarial e colocá-la dentro da calculadora, pois o Spring 
faz isso por nós. Para tal, precisamos deixar o arquivo dependencias .xml como 


o trecho a seguir. 


<?xml version="1.0" encoding="UTF-6"2> 

<beans xmlns="http://www.springframework.org/schema/beans" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://www.springframework.org/schema/beans 
http://www.springframework.org/schema/beans/spring-beans-3.0.xsd"> 
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<bean id="calculadora" 
class="br.com.casadocodigo...CalculadoraDeSalariosPlano2002"> 
<property name="tabelaDeReferenciaSalarial" > 
<ref bean="tabela"/> 

</property> 

</bean> 


<bean id="tabela" 
class="br.com.casadocodigo...TabelaDeReferenciaSalarialPadrao"> 
</bean> 
</beans> 


Podemos perceber que dentro do XML fazemos a referência do bean com id 
"tabela" dentro da propriedade tabelaDeReferenciaSalarial do bean 
"calculadora". Com isso, ao pedirmos a calculadora, o Spring instancia tam- 





bém a tabela e através do método setTabelaDeReferenciaSalarial vincula 
os dois objetos. 

Um framework como esse facilita e muito quando temos uma estrutura mais 
complexa, na qual objetos dependem de vários outros objetos, e suas dependências 
possuem dependências. Fazer uma factory na mão, como vimos antes através de 
arquivos properties, ficaria extremamente complexo e suscetível a erros. Para au- 
tomatizar um pouco mais o trabalho teríamos que usar reflexão, e ainda assim não 
chegaríamos ao nível de refinamento que um framework específico para esse fim 
pode nos proporcionar. 

Obviamente nesse exemplo mostramos algo muito simples. Assim como Seam 
e CDI, o Spring tem muito mais que isso. Os beans possuem escopos, podem ter 
interceptadores e método dinâmicos de resolução de dependência. Isso tupo porque 
a partir do momento em que chamamos o método get Bean, entramos no contexto 
do Spring, e dentro desse contexto é possível fazer muita coisa, como integração com 
módulos Java EE ou outros frameworks. Mas obviamente não iremos entrar nesses 
detalhes, pois seria assunto para um livro específico. 

O que precisamos ter em mente é que frameworks modernos quase sempre nos 
oferecem, cada um à sua maneira, as mesmas funcionalidades. A proposta dessa 
seção é apenas perceber, do ponto de vista histórico, como era o “jeitão” Spring de 
resolver dependências. 
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1.6 BUSCANDO AS DEPENDÊNCIAS COM SEAM E ANOTAÇÕES 


Como Java 5 e a inclusão de anotações, as coisas ficaram mais fáceis para o desenvol- 
vedor. Novos frameworks surgiram com uma filosofia diferente, a da configuração 
simplificada. Enquanto antes a quantidade excessiva de configuração permitia uma 
extrema flexibilidade à custa da simplicidade, a nova geração de frameworks permi- 
tia fazer muito mais configurando apenas o essencial ou a exceção. O JBoss Seam 
foi um framework que nasceu com essa filosofia. Apesar de possuir alguns passos de 
configuração, por já ter nascido na era das anotações, ele já era bem mais simples de 
se utilizar. 

Outro diferencial do JBoss Seam foi seu foco inicial na integração, possível gra- 
ças ao período em que ele surgiu, pois nesse momento o Java EE como um todo já 
tinha evoluído muito, principalmente através do EJB 3 e JPA. Isso permitiu um de- 
senvolvimento puro em Java EE tão, ou mais simples do que fazer utilizando Spring. 
Dessa forma o Seam não nasceu focado em oferecer uma stack alternativa ao Java 
EE como fez o Spring, mas sim em integrar todas as tecnologias já existentes de uma 
forma simples e elegante, coisa que ainda não existia no Java Enterprise. 

Assim como no exemplo utilizando Spring, não entraremos nas integrações do 
Seam com o Java EE, nem como ele auxilia a tratar transação ou qualquer outro 
assunto comum ao Seam, Spring ou CDI. O foco é apenas analisarmos como Seam 
trata a questão da resolução de dependências. 

Apesar de ser possível configurar utilizando XML, o Seam já nasceu com 
as anotações, então utilizá-las é o mais comum quando usamos esse fra- 
mework. Dessa forma, assim como fizemos no XML do Spring (ou faría- 
mos no XML do Seam), vamos dar nomes aos beans usando a anotação 
Gorg.jboss.seam.annotations.Name. Além disso, vamos usar também a 
anotação Borg. jboss.seam.annotations.AutoCreate para que o bean seja 
automaticamente criado quando for demandado. Sem isso, o Seam usa o bean dispo- 
nível no escopo ou devolve null. Porém como não estamos usando escopos, para 
simplificar o exemplo, precisamos de mais essa anotação. 


OCName("calculadoraDeSalarios") OAutoCreate 
public class CalculadoraDeSalariosPlano2002 
implements CalculadoraDeSalariost 


OName("tabelaDeReferenciaSalarial') QAutoCreate 
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public class TabelaDeReferenciaSalarialPadrao 
implements TabelaDeReferenciaSalarial( 


Agora que os beans já possuem nomes, precisamos referenciar a 
TabelaDeReferenciaSalarial dentro da CalculadoraDeSalarios. 
Para isso, podemos anotar tanto uma propriedade quanto seu método setter com 
Gorg.jboss.seam.annotations In. Então, alterando mais uma vez nossa 
calculadora teremos o seguinte código. 


OCName("calculadoraDeSalarios") QOAutoCreate 
public class CalculadoraDeSalariosPlano2002 
implements CalculadoraDeSalariost 


@In 
public void setTabelaDeReferenciaSalarial( 
TabelaDeReferenciaSalarial t){ 


Apesar de ficar bastante parecido com o código CDI que veremos no decorrer 
deste livro, o Seam tem uma séria limitação. A resolução da dependência é feita 
através do nome do componente, e não pelo tipo. Apesar de não termos especificado 
nenhum nome na anotação @In, o Seam considera o nome do componente a ser 
injetado como igual ao nome da propriedade anotada. Como anotamos um setter, 
o prefixo “set” é removido e a primeira letra é passada para minúsculo para obter 
o nome da propriedade correspondente. Então, na prática, é como se tivéssemos 
colocado o seguinte código In ("tabelaDeReferenciaSalarial"). 

Agora que a configuração dos beans está feita, precisamos voltar à nossa factory 
e pedira CalculadoraDeSalarios ao contexto do Seam. 


import org.jboss.seam.Component ; 
public class CalculadoraDeSalariosFactory { 


public CalculadoraDeSalarios criaCalculadora()f 
CalculadoraDeSalarios calculadora = (CalculadoraDeSalarios) 
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Component. getInstance('"calculadoraDeSalarios"); 


return calculadora; 


Apesar de usarmos menos classes, não é tão simples rodar o Seam dentro de uma 
main como conseguimos com Spring. No entanto, quero que você se foque na qua- 
lidade do código e simplicidade que teve o nosso programa, analisando como se deu 
a evolução desde o arquivo properties, passando por XML, e chegando à anotação. 
Contudo, é importante sempre lembrarmos que o Seam usa as anotações para con- 
figurar seu contexto, mas a ligação entre os beans é feita por nomes, e não por tipos 
como é na CDI. 


1.7 DE ONDE VIMOS? 


O objetivo deste capítulo foi introduzir questões básicas de OO, que são indepen- 
dentes do uso de frameworks, mas que ao serem desprezadas pode não fazer sentido 
a utilização de um. Depois passamos por um breve histórico com a evolução da 
resolução de dependências, no qual em momento algum tivemos objetivo de com- 
parar os frameworks, já que cada um pode ser utilizado de diversas maneiras e não 
necessariamente pararam no ponto em que foram apresentados aqui. 

Assim como podemos tirar proveito de um carro moderno sem nos lembrarmos 
da evolução dos carros carburados, para a injeção eletrônica, e depois os aceleradores 
eletrônicos, também podemos tirar proveito da CDI sem essa contextualização his- 
tórica. Mas quando temos esse conhecimento, entendemos melhor porque algumas 


coisas são como são, e temos um pouco mais de poder argumentativo. 
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CAPÍTULO 2 


O que é e para que serve a CDI 


2.1 PARA ONDE VAMOS? 


Neste capítulo veremos o desafio que é deixar simples de manter um sistema com 
uma regra complexa. Tal desafio é o dia a dia de muitos desenvolvedores, e provavel- 
mente em algum momento passaremos por ele, afinal, por mais que muitos sistemas 
tenham várias e várias telas de cadastro, sempre que temos que lidar com a parte cen- 
tral do sistema, onde fica sua inteligência de negócio, passaremos pelos problemas 
aqui apresentados. 


2.2 EVITANDO QUE A COMPLEXIDADE DO CÓDIGO SEMPRE 
AUMENTE 
Para iniciar nossos estudos, vamos tomar como exemplo um sistema que calcula o 


imposto de renda dos funcionários de uma empresa para informar à Receita Federal. 


Porém, como nada é simples, antes precisamos calcular o salário de cada fun- 
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cionário, e para isso será preciso analisar critérios como: cargo ou função exercida 
dentro da empresa, escolaridade, qualificações, e por fim, um critério não muito uti- 
lizado mas que serve para enriquecer nosso exemplo, o tempo de empresa. 

Facilmente percebemos que esse é um cenário de complexidade razoável, en- 
tão iremos por partes. Para começarmos, precisaremos coletar informações básicas, 
como o salário base do cargo ou função, a escolaridade do funcionário, e a escolari- 
dade esperada para o cargo. 


public double calculaImpostoDeRenda(Funcionario funcionario)( 
double salario = funcionario.getCargo().getSalarioBase(); 
Escolaridade escolaridadeFuncionario = 
funcionario.getEscolaridade(); 
Escolaridade escolaridadeCargo = 
funcionario.getCargo() .getEscolaridadeDesejada(); 


A escolaridade do funcionário e a escolaridade do cargo servem para verificar- 
mos se ele tem os requisitos esperados para a função. Isso ocorre mais frequente- 
mente quando tempos reformulações no plano de carreira de uma empresa. Se, por 
exemplo, um cargo exigia nível superior e depois passa a exigir pós-graduação, as 
pessoas com nível superior não perderão a função, mas também não receberão o 
mesmo salário dos novos funcionários que deverão ser contratados seguindo as no- 
vas exigências e com salários um pouco mais altos. 

No nosso exemplo, estamos considerando uma variação de 20% (vinte porcento) 
tanto para quem está abaixo do mínimo esperado para o cargo, quanto para quem 
tem escolaridade acima do esperado, como um mestrado por exemplo. O cálculo 
dessa diferença poderia ser feito assim: 


//se o funcionário tem escolaridade inferior à esperada para o cargo 

if (escolaridadeFuncionario.compareTo (escolaridadeCargo) < 0){ 
salario = salario * 0.8; 

} 

//se o funcionário tem escolaridade superior à esperada para o cargo 

else if(escolaridadeFuncionario.compareTo(escolaridadeCargo) > 0){ 
salario = salario * 1.2; 


Agora iremos calcular uma gratificação por tempo de serviço na empresa. Usa- 
mos uma fórmula simples, na qual, para cada ano trabalhado daremos um aumento 
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de 1% (um porcento), e em caso de permanência de pelo menos 5 anos na empresa, 
haverá um aumento extra de 10% (dez porcento). 


int anoAtual = getAnoAtual(); 
int anoAdmissao = funcionario.getAnoAdmissao(); 


//dá 1% de aumento para cada ano trabalhado na empresa 
double anosTrabalhados = anoAtual - anoAdmissao; 
double aumentoAntiguidade = anosTrabalhados / 100; 
salario = salario * (1 + aumentoAntiguidade); 


//se tem mais de 5 anos na empresa tem aumento de 10% 
if (anosTrabalhados > 5){ 
salario = salario * 1.1; 


Na maioria das vezes vale muito mais um código legível do que um número me- 
nor de linhas. Então, não se preocupe demais em fazer contas em uma única linha 
comprometendo a legibilidade e a mantenabilidade do seu código. Crie variáveis que 
expliquem o que está sendo feito, e se algo ficar muito grande, separe em métodos. 

Agora que já temos o salário bruto calculado, precisamos descontar o imposto de 
renda. No mundo real teríamos mais descontos, mas como estamos criando nosso 
próprio universo de exemplo, vamos deixar o funcionario ser mais feliz e ter 
menos descontos no seu suado salário. 

No exemplo a seguir, utilizaremos a tabela de IR de 2013, mas os dados não in- 
fluenciam muito — o mais importante é percebermos o quanto nosso código vai 
ficando complexo, e depois veremos como resolver isso. 


//tabela de IR de 2013 
double aliquota = 0.0; 
double parcelaDeduzir = 0.0; 


//ifs estão de forma mais didática, na prática poderiam ser reduzidos 
if(salario <= 1710.78)1 
aliquota = 0.0; 
parcelaDeduzir = 0.0; 
} 
else if(salario > 1710.78 && salario <= 2563.91){ 
aliquota = 7.5/100; 
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parcelaDeduzir = 128.31; 


} 

else if(salario > 2563.91 && salario <= 3418.59){ 
aliquota = 15.0/100; 
parcelaDeduzir = 320.60; 


} 
else if(salario > 3418.59 && salario <= 4271.59){ 
aliquota = 22.5/100; 
parcelaDeduzir = 577.0; 
} 
else if(salario > 4271.59){ 
aliquota = 27.5/100; 
parcelaDeduzir = 790.58; 


double impostoSemDesconto = salario * aliquota; 


return impostoSemDesconto - parcelaDeduzir; 
+ //final do método calculaImpostoDeRenda 


O cálculo de imposto de renda não é o mais simples do mundo, mas também não 
é tão complicado. Se, por exemplo, tivermos um salário de até R$ 1.710,78, estamos 
isentos do imposto, mas se tivermos um salário acima de R$ 4.271,59 estaremos na 
faixa de 27,5% do imposto. 

Mas alguém que ganha R$ 10.000,00 não vai pagar R$ 2.750,00 de IR, que se- 
ria o valor guardado na variável impostoSemDesconto; pois o desconto de 27,5% 
só incide na parcela do salário acima dos R$ 4.271,59. Por esse motivo temos a 
parcelaDeduzir, que é o valor que temos que descontar desses R$ 2.750,00 para 
chegar no imposto correto. 

Outra forma de chegar no imposto seria dividir o salário em cada faixa e calcular 
o imposto proporcional de cada uma delas e depois somar tudo. Mas na prática é para 
isso que a “parcela a deduzir” faz, já é o cálculo pronto dessa diferença. 


Juntando tudo, ao final teriamos o seguinte código: 


public double calculaImpostoDeRenda(Funcionario funcionario)( 
double salario = funcionario.getCargo().getSalarioBase(); 
Escolaridade escolaridadeFuncionario = 
funcionario.getEscolaridade(); 
Escolaridade escolaridadeCargo = 
funcionario.getCargo() .getEscolaridadeDesejada(); 
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// se o funcionário tem escolaridade inferior 

// à esperada para o cargo 

if (escolaridadeFuncionario.compareTo (escolaridadeCargo) < 0){ 
salario = salario * 0.8; 


// se o funcionário tem escolaridade superior 

// à esperada para o cargo 

else if(escolaridadeFuncionario.compareTo(escolaridadeCargo) > 0) 1 
salario = salario * 1.2; 


int anoAtual = getAnoAtual(); 
int anoAdmissao = funcionario.getAnoAdmissao(); 


//dá 1% de aumento para cada ano trabalhado na empresa 
double anosTrabalhados = anoAtual - anoAdmissao; 
double aumentoAntiguidade = anosTrabalhados / 100; 
salario = salario * (1 + aumentoAntiguidade) ; 


//se tem mais de 5 anos na empresa tem aumento de 10% 
if (anosTrabalhados > 5){ 
salario = salario * 1.1; 


//tabela de IR de 2013 
double aliquota = 0.0; 
double parcelaDeduzir = 0.0; 


// ifs estão de forma mais didática, 
// na prática poderiam ser reduzidos 
if(salario <= 1710.78)f 

aliquota = 0.0; 

parcelaDeduzir = 0.0; 


+ 

else if(salario > 1710.78 && salario <= 2563.91)1 
aliquota = 7.5/100; 
parcelaDeduzir = 128.31; 

} 

else if(salario > 2563.91 && salario <= 3418.59){ 
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aliquota = 15.0/100; 
parcelaDeduzir = 320.60; 


} 

else if(salario > 3418.59 && salario <= 4271.59){ 
aliquota = 22.5/100; 
parcelaDeduzir = 577.0; 


} 

else if(salario > 4271.59){ 
aliquota = 27.5/100; 
parcelaDeduzir = 790.58; 


double impostoSemDesconto = salario * aliquota; 


return impostoSemDesconto - parcelaDeduzir; 


Em um cenário real, ao calcular o salário ainda poderíamos ter mais variáveis, 
como gratificações, incentivos ou um diferencial por um conhecimento específico, 
mas nos limitar ao exemplo apresentado. Você deve ter se sentido desanimado em 
ler esse código, pela sua extensão, diversos casos possíveis e complexidade. Imagine 
se fosse uma aplicação real. 

Podemos perceber que o método calculaImpostoDeRenda sabe muita coisa, 
e quanto mais responsabilidades as classes possuem, mais difícil é mantê-las. 

Agora consideremos que para um método desse tipo estar em produção, ele pre- 
cisa estar testado. E mais do que isso, ele precisa de testes automatizados, pois testes 
manuais além de trabalhosos tendem a não ser tão metódicos e reproduzíveis. Mas 
como testar um método sabichão? Acredito que esse seja um bom candidato para 
uma “queima de arquivo’, pois ele sabe demais. 

Mesmo antes de pensarmos em testar, precisamos organizar esse cálculo. Uma 
ótima ideia seria separar a calculadora de salários da calculadora de IR. Olhando o 
método completo, que é enorme, percebemos duas partes bem distintas dentro dele, 
claramente duas operações diferentes mas que estavam juntas no mesmo método: o 
cálculo do salário bruto, e o cálculo do IR. 

Vamos então criar uma classe que tem como responsabilidade calcular só o sa- 
lário bruto, assim caso essa regra mude, alteramos essa classe e não corremos o risco 
de danificar o cálculo do IR, pois eles ficarão independentes a partir de agora. 


O código a seguir nós já conhecemos, só vamos separá-lo em uma classe: 
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public class CalculadoraDeSalarios { 
public double calculaSalario (Funcionario funcionario)f 
double salario = funcionario.getCargo().getSalarioBase(); 
Escolaridade escolaridadeFuncionario = 
funcionario.getEscolaridade(); 
Escolaridade escolaridadeCargo = 
funcionario.getCargo() .getEscolaridadeDesejada(); 


// se o funcionário tem escolaridade inferior 

// à esperada para o cargo 

if (escolaridadeFuncionario.compareTo (escolaridadeCargo) < 0) 
salario = salario * 0.8; 

} 

// se o funcionário tem escolaridade superior 

// à esperada para o cargo 

else if( 
escolaridadeFuncionario.compareTo (escolaridadeCargo) > 0) { 
salario = salario * 1.2; 


int anoAtual = getAnoAtual(); 
int anoAdmissao = funcionario.getAnoAdmissao(); 


//dá 1) de aumento para cada ano trabalhado na empresa 
double anosTrabalhados = anoAtual - anoAdmissao; 
double aumentoAntiguidade = anosTrabalhados / 100; 
salario = salario * (1 + aumentoAntiguidade); 


//se tem mais de 5 anos na empresa tem aumento de 10% 
if (anosTrabalhados > 5){ 
salario = salario * 1.1; 


return salario; 


Agora temos uma classe que só sabe calcular salários, e que ainda poderia ser 
melhorada, separando cada critério como escolaridade ou qualificação, funções ou 
cargos, e antiguidades em subcalculadoras. Estas encapsulariam cada lógica de cál- 
culo específica e no final a calculadora geral combinaria os resultados. Mas faremos 
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isso em momento oportuno, o principal agora é vermos onde a CDI vai nos ajudar. 


Com a separação, nossa calculadora de IR ficou bem mais simples: 


public class CalculadoraDeImpostos { 
public double calculaImpostoDeRenda (Funcionario funcionario)( 
CalculadoraDeSalarios calculadora = new CalculadoraDeSalarios(); 
double salario = calculadora. calculaSalario (funcionario); 


//tabela de IR de 2013 
double aliquota = 0.0; 
double parcelaDeduzir = 0.0; 


// ifs estão de forma mais didática, 
// na prática poderiam ser reduzidos 
if(salario <= 1710.78)t 
aliquota = 0.0; 
parcelaDeduzir = 0.0; 
} 
else if(salario > 1710.78 && salario <= 2563.91){ 
aliquota = 7.5/100; 
parcelaDeduzir = 128.31; 
} 
else if(salario > 2563.91 && salario <= 3418.59){ 
aliquota = 15.0/100; 
parcelaDeduzir = 320.60; 
} 
else if(salario > 3418.59 && salario <= 4271.59){ 
aliquota = 22.5/100; 
parcelaDeduzir = 577.0; 
} 
else if(salario > 4271.59){ 
aliquota = 27.5/100; 
parcelaDeduzir = 790.58; 


double impostoSemDesconto = salario * aliquota; 


return impostoSemDesconto - parcelaDeduzir; 
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REFATORAÇÃO E TESTABILIDA DE 


Nas aplicações que já temos, separar essas responsabilidades em clas- 
ses distintas nem sempre é tão simples. Pode ocorrer de em uma aplica- 
ção similar o cálculo do salário e dos descontos irem ocorrendo de forma 
entrelaçada, uma vez parte de um, outra parte de outro. 

Nesse caso pode ser interessante inverter a ordem que usamos aqui, e 
caso não existam, primeiro criar os testes que garantam o funcionamento 
do método que queremos refatorar. Depois de testado, aí sim faríamos 
uma refatoração completa, separando as responsabilidades, e então usa- 
ríamos os mesmos testes para garantir que a refatoração não danificou o 
funcionamento. 

Somente depois que os testes estivessem todos verdes (executados 
com sucesso) é que aproveitaríamos os métodos de negócio mais bem 
escritos para melhorar também o código dos nossos testes. 








ENTENDENDO MAIS DE TESTES AUTOMATIZADOS 


Teste de código é uma matéria ampla, tato é que temos excelentes li- 
vros sobre o assunto [?]. Assim sendo, o objetivo aqui não é cobrir total- 
mente esse assunto, e sim falar um pouco sobre como isso é importante 
no desenvolvimento de software. 

A CDI não amarra nosso projeto de classes, nos dando liberdade para 
um projeto bem testável. No entanto, em alguns momentos precisamos 
mais do que testes de unidade, como testes de integração e de sistema. 
Quando passamos para os testes de integração, ferramentas como CDI 
costumam dar trabalho, mas no capítulo 9 veremos como isso pode ser 
feito sem muito trabalho. 











Agora sim podemos partir para os testes. Vamos considerar um funcionário com 
salário de R$ 3.000,00. Teremos que verificar se o imposto dele foi de R$ 129,40, pois 
ele caiu na alíquota de 15% e sua parcela a deduzir é de R$ 320,60. Não parece muito 
complicado, não é verdade? Seria algo parecido com o seguinte código. 


OTest 
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public void testaCalculoIRNaSegundaFaixaDeContribuicao (0) 
Funcionario funcionario = new Funcionario(); 
funcionario.setSalario(3000.0); // esse método não existe 


CalculadoraDeImpostos calculadora = 
new CalculadoraDeImpostos() ; 


//a calculadora de IR usa outra classe para calcular o salário 
double impostoDeRenda = 
calculadora. calculaImpostoDeRenda (funcionario); 


Assert.assertEquals (129.4, impostoDeRenda, 0.0001); 


O detalhe é que esse salário de R$ 3.000,00 não pode ser atribuído assim, ele 
é calculado pela CalculadoraDeSalarios dentro do cálculo do IR. Isso quer 
dizer que temos dois cálculos acontecendo dentro do mesmo teste, e isso pode causar 
confusão. 

No nosso caso, teríamos que configurar o funcionario com dados que sa- 
beríamos que ao final do cálculo do salário bruto, teríamos R$ 3.000,00 como 
resultado. Mas pode ocorrer de configurarmos o funcionário corretamente e a 
CalculadoraDeSalarios de falhar, devolvendo um valor errado. Então, esta- 
ríamos testando o imposto achando que o salário bruto era 3000.0 mas na prática 
o valor seria outro, e o teste falharia. 

O pior nesse exemplo é que o teste que estamos escrevendo chama-se 
testaCalculoIRNaSegundaFaixaDeContribuicao, então se ele falhar, a pri- 
meira coisa que virá às nossas mentes é que o cálculo do IR está com problemas, e 
não que o erro foi no cálculo do salário. Mas como lidar com esses casos? 

Poderíamos nesse ponto ser um pouco impulsivos e sair alterando a assi- 
natura do método que calcula o imposto de renda para este receber o salário 
já calculado, apenas um double, e então eliminaríamos a dependência com a 
CalculadoraDeSalarios nos nossos testes. 

Essa pode ser, sim, uma das soluções, mas veremos que temos outras mais apli- 
cáveis a qualquer modelo. Além do mais, se formos tentar mudar as assinaturas dos 
nossos métodos para receber dados mais independentes, já processados, em pouco 
tempo estaremos trabalhando somente com tipos simples de dados (primitivos e 
wrappers), e acabaremos com a OO, que tem como base a colaboração entre objetos. 


A solução mais adequada para promover a testabilidade do nosso código sem 
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ferir a OO é o uso da Injeção de Dependências, ou Dependency Injection (DI) em 
inglês. 


2.3 INTRODUÇÃO À INJEÇÃO DE DEPENDÊNCIAS 


A injeção de dependências é muito importante para termos um sistema mais simples 
de manter. Apesar de parecer que sua principal vantagem é ajudar nos testes, isso na 
verdade é só uma forma de percebermos sua real vantagem, que é a facilidade em 
trocar peças do nosso sistema diminuindo muito a possibilidade de quebra. Vamos 
voltar ao nosso exemplo para entendermos melhor como isso funciona. 


public class CalculadoraDeImpostos { 
private CalculadoraDeSalarios calculadoraSalarios; 


public CalculadoraDeImpostos (CalculadoraDeSalarios calculadora)( 
calculadoraSalarios = calculadora; 


public double calculaImpostoDeRenda (Funcionario funcionario)( 
double salario = calculadoraSalarios.calculaSalario(funcionario); 


//resto do método continua igual 


A principal mudança no desenho das classes é o que fizemos na 
CalculadoraDeImpostos. Na versão anterior de seu código, essa classe 
instanciava diretamente a classe CalculadoraDeSalarios, e assim não conse- 
guíamos de uma forma simples interferir na relação entre uma classe e outra. Agora, 
apesar de sutil, a mudança é poderosa; pois a classe que antes ativamente resolvia a 
dependência agora espera pacientemente que alguém lhe supra essa dependência. E 
quando esse alguém (nós mesmos ou um framework) passa essa dependência para a 
classe que necessita, dizemos que ele está injetando a dependência em quem precisa. 

Nesse primeiro momento nós mesmos estaremos passando para a 
CalculadoraDeImpostos a instância de CalculadoraDeSalarios que 
ela necessita, ou seja, a injeção de dependência será manual, mas é aqui que a CDI 
atuará, suprindo “automaticamente” essas dependências. Veremos mais à frente 
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que, apesar das aspas, esse processo é tão simples que poderemos, sim, na grande 
maioria dos casos, considerá-lo automático. 

Já fizemos as alterações na classe que possui a dependência, agora falta alterar 
nosso teste para injetar essa dependência da forma correta. 


OTest 

public void testaCalculoIRNaSegundaFaixaDeContribuicao (0) 
Funcionario funcionario = new Funcionario(); 
funcionario.setSalario(3000.0); //esse método não existe 


CalculadoraDeSalarios calculadoraSalarios 
new CalculadoraDeSalarios(); 


CalculadoraDeImpostos calculadoraImpostos 
new CalculadoraDeImpostos (calculadoraSalarios); 


//a calculadora de IR usa outra classe para calcular o salário 
double imposto = 
calculadoraImpostos.calculaImpostoDeRenda (funcionario); 


Assert.assertEquals(129.4, imposto, 0.0001); 


Esse passo foi apenas didático, pois não elimina nosso problema, apenas mostra 
como devemos montar a instância de CalculadoraDeImpostos. Para obtermos 
uma vantagem de verdade, precisaremos trocar a calculadora de salários. Criaremos 
uma nova classe para substituira CalculadoraDeSalarios, e essa nova classe vai 
servir somente para nossos testes. Em vez de calcular de verdade, ela vai devolver 
o valor que especificarmos, assim não teremos mais a dependência entre as duas 


calculadoras dentro do mesmo teste. 


public class CalculadoraDeSalariosMock extends CalculadoraDeSalarios { 
private double salarioFixo; 


public CalculadoraDeSalariosMock (double salarioFixo)f 
this.salarioFixo = salarioFixo; 


} 
public double calculaSalario(Funcionario funcionario){ 
return salarioFixo; 
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Na classe CalculadoraDeSalariosMock nós estendemos a classe 
CalculadoraDeSalarios e sobrescrevemos o método calculaSalario 
para que ele funcione da forma que desejamos. É um serviço grande para um 
resultado simples, mas não se preocupe, existem frameworks que fazem isso sem a 
necessidade de criarmos uma nova classe, um Mock. 





CRIAÇÃO SIMPLIFICADA DE MOCKS COM FRAMEWORKS 


Mocks são objetos “burros”, programados para responder exatamente 
como precisarmos em cada situação. No nosso exemplo mandamos ele 
simplesmente retornar um valor, independentemente do que o método 
calculaSalario semanticamente representa. 

Existem frameworks que facilitam bastante o trabalho como o Moc- 
kito, que será usado nos códigos de exemplo a partir do capítulo 10. 











Apesar do trabalho a mais, fazer essa classe nos mostra que se tivéssemos defi- 
nido a CalculadoraDeSalarios como uma interface, e não como uma classe, 
nosso Mock ficaria semanticamente melhor. O mock em si não é um problema pois 
no futuro vamos usar um framework para criá-lo sob demanda, mas caso precisemos 
em um determinado momento alterar a forma de calcular os salários, por exemplo 
depois de um novo plano de cargos e salários, poderemos cair no mesmo problema 
que vemos no exemplo. 


Princípio da substituição de Liskov e o uso de interfaces 


Quando precisamos trocar um objeto por outro, como no caso trocamos nossa 
calculadora real pelo mock, e no caso de um novo planos de cargos, aplicamos o 
Princípio da substituição de Liskov, segundo o qual o objeto mock consegue perfei- 
tamente se passar pelo objeto real. 

Perceba porém que para fazermos isso funcionar foi preciso que o mock seja 
subclasse da CalculadoraDeSalarios, o que do ponto de vista semântico não 
tem sentido algum. Novamente imaginemos isso aplicado no caso da criação de um 
novo plano de cargos, em que a implementação original será desprezada, mas para 
que conseguíssemos fazer a nova calculadora substituir a primeira, precisaríamos 
que esta fosse subclasse da primeira. Caso usássemos uma interface não teríamos 
esse problema. 


33 


2.3. Introdução à injeção de dependências Casa do Código 





Após entendermos um pouco mais sobre como um objeto substitui outro, vamos 
aplicar isso no nosso teste. 


OTest 
public void testaCalculoIRNaSegundaFaixaDeContribuicao (0) 
Funcionario funcionario = new Funcionario(); 


CalculadoraDeSalarios calculadoraSalarios 
new CalculadoraDeSalariosMock(3000.0); 


CalculadoraDeImpostos calculadoraimpostos 


new CalculadoraDeImpostos (calculadoraSalarios); 


//a calculadora de IR usa outra classe para calcular o salário 
double imposto = 


calculadoraImpostos.calculaImpostoDeRenda (funcionario); 


Assert.assertEquals(129.4, imposto, 0.0001); 


Agora sim temos um código funcionando. Criamos manualmente um mock uti- 
lizando o princípio da substituição e injetamos esse mock como dependência da 
CalculadoraDeImpostos. Nada mal para um início. Acredito que foi possível 
perceber o quanto algo simples, como a injeção de dependências, pode fazer uma 
diferença na modularidade do nosso sistema, trocando uma classe por outra sem 
que as classes clientes percebam. 


34 


Casa do Código Capítulo 2. O que é e para que serve a CDI 








PRINCÍPIO DE LISKOV 


Esse princípio descreve o que é necessário para fazer um objeto ser 
aceito no lugar de outro. Basicamente o novo objeto tem que ser um sub- 
tipo, ou em Java implementar a mesma interface que o primeiro. Além 
disso, os métodos da subclasse têm que aceitar no mínimo tudo que o 
método da superclasse aceita, e devolver no máximo o que o primeiro 
devolvia. 

Como exemplo, podemos considerar um método que receba e de- 
volva números. Se a classe original aceita apenas números positivos, a 
nova classe tem que no mínimo aceitar todos os números que a primeira 
aceitava, mas se ela aceitar também os números negativos não tem pro- 
blema. Nesse caso, provavelmente num primeiro momento a opção de 
enviar números negativos não será usada pelo sistema, visto que ele já 
está condicionado à primeira classe que só aceita números positivos. Já 
se a nova classe aceitar menos que a original, por exemplo somente nú- 
meros maiores que mil, o sistema pode passar para essa nova classe o 
número 50, pois com a classe original era possível, mas na nova isso ge- 
raria um erro em tempo de execução. 

A respeito do retorno, o princípio é o inverso: se a classe original re- 
torna somente números positivos, podemos no máximo devolver os nú- 
meros positivos na nova classe. Isso porque o sistema já vai estar condici- 
onado a esperar apenas números positivos, então ao retornar um número 
negativo poderíamos ter um erro em tempo de execução. Agora se retor- 
narmos uma quantidade ainda mais restrita de resultados não teremos 
problema, como retornar apenas valores maiores que mil. 

É possível percebermos que quanto à tipagem, as linguagens de pro- 
gramação dão conta do recado, já as restrições de entrada e saída dos 
métodos na maioria das vezes precisam ser tratadas pelo desenvolvedor, 
e por isso podemos considerar que a interface de uma classe não é só a 
assinatura de seus métodos, mas também as restrições que, quando exis- 
tirem, devem estar especificadas via JavaDoc ou outra forma efetiva de 
documentação. 
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2.4 A MOTIVAÇÃO DA CDI 


Nosso exemplo até aqui foi simples, mas conforme ele for aumentando sentiremos 
cada vez mais a necessidade de algum gerenciador dessas dependências. 

O mais importante nesse capítulo, é percebermos que conforme o sistema cresce, 
e vamos nos preocupando e mantê-lo organizado e testado, vai surgindo a necessi- 
dade de um auxílio. 

Precisamos de uma ferramenta que nos dê a possibilidade de montar nossos ob- 
jetos a partir de outros, como um “lego”. Porém essa ferramenta preferencialmente 
precisa nos livrar de configurações morosas, cheias de XML; e também de configura- 
ções simples, com anotações, mas que não conseguem analisar os tipos dos objetos, 
como vimos na seção 1.3. E é aqui que entra a CDI. 

A CDI é uma especificação Java, cujo nome completo é “Context and Depen- 
dency Injection for Java EE” [2], mas como podemos perceber o “for Java EE” não 
entra na sigla. De fato, conforme formos nos aprofundando no assunto, vamos per- 
ceber que a CDI não é apenas para o Java EE, mas também para o Java SE. 

Se você está iniciando no universo Java, pode ser que não esteja habituado com 
o termo “especificação”, mas fique tranquilo, trataremos disso logo a seguir. E para 
nos ajudar a lembrar sempre que estamos falando de uma especificação, procurarei 
sempre me referir à CDI no gênero feminino. Pois não falamos de um framework, e 
sim de uma especificação. 


2.5 O QUE É E PARA QUE SERVE UMA ESPECIFICAÇÃO? 


Apesar do convencimento da real necessidade de algo só vir quando nos depara- 
mos com casos mais complexos, com os exemplos apresentados percebemos que há 
vantagem no uso da injeção de dependência, e no decorrer do livro teremos certeza 
disso. Tanto que um indicador da importância de uma matéria é a quantidade de 
pessoas tentando resolver seus problemas. 

Quando o assunto é injeção de dependência, temos no ecossistema Java algumas 
opções de frameworks, sendo os mais conhecidos e modernos o Spring Framework 
e o JBoss Seam, já apresentados na seção 1.3. 

Apesar de serem duas boas ferramentas, Spring e Seam são frameworks diferen- 
tes, e adotando qualquer um dos dois a mudança para outro framework que faça a 
mesma tarefa é muito custosa, não valendo a pena. Dessa forma caso o framework 
que estivermos utilizando comece a apresentar um nível elevado de bugs ou tenha 
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seu desenvolvimento descontinuado, nossa aplicação corre sérios riscos de ficar de- 
satualizada ou ter falhas graves. 

Por esse motivo surgem as especificações. Elas definem como uma determinada 
funcionalidade deve se comportar e os implementadores (empresas, fundações, gru- 
pos de usuários, indivíduos etc) têm liberdade de implementar da maneira que de- 
sejarem, desde que a especificação seja seguida. 

Na prática, ela é um documento texto que especifica cada funcionamento es- 
perado do software que a implemente. Com isso temos a facilidade de escolher a 
implementação que mais nos agradar, e caso a mesma seja descontinuada ou sua 
qualidade não nos satisfaça mais, podemos trocar de implementação com pouco es- 
forço, visto que via de regra o comportamento de todas elas deve ser igual ou bem 
parecido. E para garantir que esse funcionamento seja padrão, existe uma bateria de 
testes que são aplicados a uma implementação que queira se certificar como aderente 
à especificação. 

A CDI — Context and Dependency Injection for Java EE — é a especificação 
que rege como deve funcionar os frameworks de injeção de dependências para a 
plataforma Java. Dessa forma, agora temos uma maior liberdade de escolha na im- 
plementação, e mesmo frameworks que não a implementam acabam tendo um com- 
portamento parecido com o da especificação, para que seja possível reutilizar o co- 
nhecimento e até mesmo código vindo de aplicações feitas com implementações de 
CDI. 

Quando estivermos estudando especificamente a CDI, veremos que ela trouxe 
uma inovação em relação às outras especificações. É muito comum uma implemen- 
tação trazer funcionalidades a mais do que a especificação determina, pois a veloci- 
dade da demanda da comunidade é superior à do comitê que evolui as especificações. 
Isso é muito bom pois temos novidades em uma velocidade maior, mas quando uti- 
lizamos essas funcionalidades não especificadas, acabamos nos prendendo a uma 
implementação específica, pois uma outra implementação pode não ter tal funcio- 
nalidade ou tê-la de forma diferente. 

Por ser isso comum, a CDI já especificou como criar extensões portáveis entre 
implementações, com isso se estivermos utilizando o Weld (da JBoss), implementa- 
ção de referência, e quisermos mudar para a OpenWebBean (da Apache), poderemos 
levar para essa segunda, as extensões desenvolvidas pela primeira, desde que tais ex- 
tensões sejam implementadas seguindo as regras de portabilidade. É realmente algo 
muito interessante e que faz falta em outras especificações. No capítulo 9 veremos 
especificamente sobre essas extensões. 
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2.6 A CDI É só PARA JAVA EE MESMO? 


Apesar de seu nome, Context and Dependency Injection for Java EE, a CDI é uma es- 
pecificação que pode ser utilizada em ambiente Enterprise ou em ambiente Standard, 
como dentro de um Tomcat, Jetty, ou até mesmo em uma aplicação Desktop. Esse 
nome não quer dizer onde a CDI roda, mas sim onde ela vem pronta para uso, que 
no caso é no ambiente Java EF, tanto no profile Full quanto no Web. 

Até a versão 5, o Java EE era uma coleção enorme de especificações que, juntas, 
nos permitem desenvolver os mais variados tipos de aplicação, mas tinha muito mais 
funcionalidades do que a grande maioria das aplicações costuma usar. Por isso, a 
partir da versão 6, o Java EE passou a ter diferentes perfis: o Full e o Web. O Full, 
ou completo, é o equivalente à coleção do Java EE 5 e mais algumas especificações 
novas, dentre elas a CDI. Já o perfil Web é um subconjunto dessas especificações, 
contendo apenas as especificações mais úteis para as aplicações mais comuns. 

Acontece no entanto de haver aplicações que usam ainda menos recursos do que 
os disponibilizados no perfil Web do Java EE, como uma aplicação que utilize JSF e 
JPA [2]. Esse tipo de aplicação precisa apenas de um Servlet Container, e apesar de 
ser uma aplicação web, nesse caso consideramos que ela está sobre a plataforma Java 
SE. Logo, não podemos confundir aplicações Java SE com aplicações Desktop, mas 
a CDI pode ser utilizada em ambos. 
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CAPÍTULO 3 


Iniciando um projeto com CDI 


Nos capítulos anteriores apenas iniciamos a conversa sobre CDI, que obviamente 
vai durar todo esse livro. Mas agora, nesses primeiro exemplos, já conseguiremos 
entender um pouco mais dos motivos que fazem da CDI uma ótima alternativa para 
utilizarmos nos nossos projetos. 

Os exemplos desse livro serão baseados na IDE Netbeans, e no servidor de apli- 
cação GlassFish 4, mas todos os conceitos são independentes de IDE e de Servidor. 
Utilizaremos também a implementação de referência, Weld, mas toda implementa- 
ção certificada deve funcionar de forma semelhante. 

Para facilitar o passo a passo, você pode clonar esse repositório no Github: https: 
/lgithub.com/gscordeiro/livro-cdi. 


3.1 OLÁ CDI 


Vamos aproveitar o exemplo da CalculadoraDeImpostos visto anteriormente e 
agora vamos colocá-la para funcionar com a CDI. Iniciaremos com uma Servlet, que 
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é uma classe Java que roda no servidor e é alcançável por uma URL. Esse primeiro 
código terá objetivo apenas didático, não vai fazer parte da versão final do sistema. 

Para iniciar, faça o download (https://netbeans.org/downloads) da versão Java 
EE ou da versão Full (Tudo) do netbeans, pois assim já virá com o servidor GlassFish 
4. Com a IDE aberta, crie uma aplicação Web e lhe atribua um nome. Quando for 
perguntado, informe que será uma aplicação Java EE 7. 

Caso esteja usando Eclipse, você pode adicionar o servidor ao criar um novo 
projeto, indo em “New > Dynamic Web Project” e dê ao projeto o nome que preferir. 
Logo após especificar o nome do projeto, você poderá escolher o servidor (Target 
runtime). 

Iremos iniciar nosso exemplo com uma Servlet. As IDEs possuem formas espe- 
cíficas para a criação de Servlets, mas nada que fuja muito de um clique com o botão 
direito, escolher a criação de uma nova Servlet e através de wizard especificar qual 
padrão de url e quais métodos pretendemos utilizar. No nosso exemplo especifica- 
mos respectivamente /hello-cdi eo método doGet. 


OwebServlet ("/hello-cdi") 
public class IniciandoComCDI extends HttpServlet { 


OInject 
private CalculadoraDeImpostos calculadoralmpostos; 


public IniciandoComCDI() 1 


System.out.printin("Instanciando a Servlet...'"); 


OPostConstruct 
public void ok(){ 
System.out.println("Servlet pronta."); 


protected void doGet (HttpServletRequest req, 
HttpServletResponse res) 
throws ServletException, IOException { 


double salarioBase = 
Double.parseDouble(req.getParameter("salario")); 


Funcionario funcionario = new FuncionarioBuilder() 
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.comSalarioBaseDe (salarioBase) 
«build (); 


System.out.printin("Efetuando o cálculo."); 


//a calculadora de IR usa outra classe para calcular o salário 
double imposto = 
calculadoraImpostos.calculaImpostoDeRenda (funcionario); 


res.getOutputStream() .print( 
String.format ("Salario base: R$ %.2f\n" + 
"Imposto devido: R$ K.2f", salarioBase, imposto)); 
System.out.printin("Fim.'"); 


Não me importei em escrever diretamente no console (saída padrão) da aplica- 
ção. Além é claro de escrever na tela o resultado do cálculo. 

Optei por uma servlet por esta ser a API mais básica do Java para a Web, dessa 
forma não precisamos de muito conhecimento acumulado para entender o exemplo. 

Perceba que esse código faz uso das mesmas classes utilizadas no 
testaCalculoIRNaSegundaFaixaDeContribuicao, então não se pre- 
ocupe em entender o sentido do cálculo, e sim a dinâmica de resolução das 
dependências. 

Como já estamos utilizando a CalculadoraDeImpostos junto com a 
CalculadoraDeSalarios, sem mocks, precisamos criar um funcionário de ver- 
dade, e por isso utilizamos a classe FuncionarioBuilder, que facilita o processo 
de criação desse objeto. 


public class FuncionarioBuilder { 


private int anoAdmissao; 

private Escolaridade escolaridadeFuncionario; 
private Escolaridade escolaridadeCargo; 
private double salarioBase; 


public FuncionarioBuilder() { 


escolaridadeCargo = Escolaridade.SUPERIOR; 
escolaridadeFuncionario = Escolaridade .SUPERIOR; 
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anoAdmissao = Calendar.getInstance().get (Calendar. YEAR); 


public FuncionarioBuilder comSalarioBaseDe (double salarioBase)( 
this.salarioBase = salarioBase; 


return this; 


public Funcionario build(){ 
Cargo cargo = new Cargo(salarioBase, escolaridadeCargo) ; 
return new Funcionario (cargo, 
escolaridadeFuncionario, 
anoAdmissao); 


Esse código é necessário pois a criação do Funcionário envolve a criação de 
Cargo, e como precisaremos criar um funcionário diversas vezes, como nos tes- 
tes, a maneira de facilitar a criação dos objetos como queremos é via essa classe, que 
implementa o padrão builder. 

Na CalculadoraDeImpostos, apenas adicionamos a anotação @Inject no 
construtor para que a CDI saiba que precisa injetar essa dependência para nós. Fora 
isso, assim como já vimos no código da servlet, utilizamos um método público e sem 
argumentos anotado com a anotação GPostConstruct, que é chamado pela CDI 
sempre que o objeto está pronto, ou seja, já teve todas suas dependências satisfeitas. 


import javax.annotation.PostConstruct; 
import javax.inject.Inject; 


public class CalculadoraDeImpostos { 
private CalculadoraDeSalarios calculadoraSalarios; 
OInject 
public CalculadoraDeImpostos (CalculadoraDeSalarios calculadora)( 


System.out.println("Iniciando Calculadora de impostos..."); 
calculadoraSalarios = calculadora; 
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OPostConstruct 
public void init(){ 
System.out.println("Calculadora de impostos pronta!"); 


//resto do código permanece igual... 


Também para facilitar a análise da sequência da resolução das dependências é 
que alteramos um pouco a CalculadoraDeSalarios para escrever no console 
quando ela começa a ser instanciada e quando ela estiver pronta. 


import javax.annotation.PostConstruct; 
public class CalculadoraDeSalarios 1 


public CalculadoraDeSalarios() 1 
System.out.println("Iniciando Calculadora de salários..."); 


OPostConstruct 
public void init(){ 
System.out.println("Calculadora de salários pronta!"); 


//resto do código permanece igual... 


Ainda existe um detalhe antes de executarmos nosso exemplo. Como 
criamos uma classe CalculadoraDeSalariosMock que estende a 
CalculadoraDeSalarios, quando a CalculadoraDeImpostos solicitar 
a dependência via seu construtor, a CDI ficará em dúvida de qual implementação 
utilizar para satisfazer a dependência, se a calculadora real ou a mock, pois ambas 
têm tipos compatíveis com a dependência. Por isso colocaremos a anotação 
@Vetoed na classe mock, indicando à CDI que essa classe não deve ser considerada 
uma candidata à resolução de dependências. 


import javax.enterprise.inject.Vetoed; 
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OVetoed 
public class CalculadoraDeSalariosMock extends CalculadoraDeSalarios { 
//conteúdo permanece igual 


Caso esteja utilizando a versão 1.0 da CDI, em que esta anotação não está dispo- 
nível, você pode usar a anotação Gjavax.enterprise.inject.Alternative 





no lugar da GVetoed. Essa anotação também marca o bean como não elegível em 
um primeiro momento, mas nos permite reativá-lo posteriormente via configuração. 
Mas não se preocupe com essa anotação por enquanto, veremos mais detalhes dela 
na seção 4.3. 

Agora, analisando as classes CalculadoraDeImpostos e 
CalculadoraDeSalarios podemos perceber algo interessante, elas não 
precisam de nenhuma anotação para que a CDI as detecte e consiga utilizá-las. 
Tanto é que tivemos que colocar uma anotação no mock para que ela também não 
fosse considerada automaticamente. Fora essa, a outra anotação que temos é a da 
Servlet, que está ali porque precisamos mapear um padrão de url para ela, e não por 
causa da CDI. 

Se executarmos o exemplo através da seguinte url: http://localhost:8080/livro-cdi/ 
hello-cdi?salario=3000 , teremos esse resultado. 


800 
(<)> [99 || @ localhost:8080/livro-cdi/hello-cdi?salario=3000 
E http://localhos...di?salario=3000 JT 


Salario base: R$ 3000,00 
Imposto devido: R$ 129,40 








Figura 3.1: Hello world com CDI 


Podemos ver que o resultado foi o mesmo dos testes vistos antes, mas o resultado 
não é o mais importante, o principal objetivo é entendermos como o processo todo 
funciona. Se analisarmos a saída no console da aplicação, teremos algo como isso: 


Instanciando a Servlet... 
Iniciando Calculadora de salários... 
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Calculadora de salários pronta! 
Iniciando Calculadora de impostos... 
Calculadora de impostos pronta! 
Servlet pronta. 

Efetuando o cálculo. 

Fim. 


Com esse exemplo bem simples já conseguimos perceber a dinâmica básica 
da resolução de dependências. Ao instanciar a Servlet IniciandoComCDI, a 
CDI percebeu que ela precisava de uma instância de CalculadoraDeImpostos, 
e por isso logo depois de instanciar o primeiro objeto, já começou a providen- 
ciar sua dependência. Porém, por mais que a Servlet não tenha uma dependên- 
cia direta da CalculadoraDeSalarios, sem esta não é possível instanciar a 


CalculadoraDeImpostos. 





Como utilizamos a injeção da CalculadoraDeSalarios no construtor da 











CalculadoraDeImpostos, não tem como a CDI iniciar a instanciação desta en- 
quanto aquela não estiver pronta. Apenas didaticamente, se fizéssemos a seguinte 
alteração teríamos uma saída diferente: 


import javax.annotation.PostConstruct; 
import javax.inject.Inject; 


public class CalculadoraDeImpostos { 
OInject 


private CalculadoraDeSalarios calculadoraSalarios; 


public CalculadoraDeImpostos Of 
System.out.println("Iniciando Calculadora de impostos..."); 


OPostConstruct 
public void init(){ 
System.out.printin("Calculadora de impostos pronta!"); 


//resto do código permanece igual... 
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Após essa alteração, a saída no console seria a seguinte: 


Instanciando a Servlet... 

Iniciando Calculadora de impostos... 
Iniciando Calculadora de salários... 
Calculadora de salários pronta! 
Calculadora de impostos pronta! 
Servlet pronta. 

Efetuando o cálculo. 

Fim. 


Podemos perceber que a CDI resolve a ordem em que os objetos precisam 
ser instanciados. Depois de instanciar a CalculadoraDeSalarios, ela é inje- 
tada na CalculadoraDeImpostos, e como essa era sua única dependência, a 
CalculadoraDeImpostos é avisada que está pronta, através de seu método ano- 
tado com EPostConstruct. Agora que está completa, ela é injetada na Servlet, 
que também é avisada que está pronta. Somente depois do ambiente pronto é que a 
requisição é atendida e o cálculo é efetuado. 

Como observamos no exemplo, para solicitar a injeção de uma dependência 
basta utilizarmos a anotação Gjavax.inject.Inject. Dessa forma a CDI pro- 
cura em seu contexto uma classe candidata a suprir essa dependência, e como por 
padrão toda classe dentro de um pacote CDI é candidata a ser injetada, não pre- 
cisamos fazer nenhuma configuração nas classes. Veremos que em alguns casos é 
interessante especificarmos algumas características adicionais, mas isso é a exceção, 
pois o default já nos serve para a maioria dos casos. Defaults inteligentes são uma 
das marcas da CDI. 
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3 





O uso DO @POSTCONSTRUCT 


Quando usamos CDI, ou mesmo outro framework que gerencia as 
dependências das nossas classes, precisamos ficar atentos sobre o fato de 
que o método que representa a instanciação em si não é a chamada do 
construtor, e sim, o método anotado com GPostConstruct, pois na 
invocação desse método sim temos certeza que o objeto está pronto. 

Então, se pretendíamos fazer alguma programação no construtor, 
pode ser interessante fazer no GPostConstruct, pois nele, indepen- 
dentemente se a injeção de dependência foi via construtor, método ini- 
cializador ou diretamente nas propriedades, saberemos que o objeto está 
pronto. É uma espécie de construtor lógico do objeto. 

Um exemplo disso é quando temos serialização de um objeto, como 
na passivação de um EJB. Pode ser que o container serialize o objeto 
quando ele se torna inativo e depois o retorne para a memória quando 
ele for usado novamente. Quando isso ocorre, uma nova instância é cri- 
ada, e consequentemente seu construtor precisará ser invocado, pois é 
o construtor físico, já o método anotado com GPostConstruct, cons- 
trutor lógico, não será invocado, pois trata-se do mesmo bean. Ele não 
está sendo construído, criado naquele momento, só está retornando ao 
estado original. 











.2 O QUE É UM PACOTE CDI? 


Acabamos de ver que, por padrão, toda classe dentro de um pacote CDI é elegível 


para suprir uma dependência. Mas o que é um pacote CDI? E aquelas classes utili- 


tárias que nós já temos prontas dentro de um jar, como podemos injetar instância 


delas dentro da nossa aplicação? 


Como estamos trabalhando com uma aplicação Web (war), basta colocarmos 





um arquivo chamado beans .xml dentro da pasta WEB-INF da nossa aplicação. 


Agora se tiver um jar simples ou ejb-jar, colocamos esse arquivo dentro da pasta 


MI 





ETA-INF e pronto, a configuração da CDI está pronta. 


Nesse ponto podemos nos perguntar: mas e as configuração da CDI, onde colo- 


camos? 


A resposta está novamente em defaults inteligentes. Como até aqui não precisa- 
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mos fazer configuração alguma, não precisamos sequer definir uma estrutura xml 
mínima dentro desse arquivo. Basta que ele exista com esse nome, mesmo estando 
vazio, que a CDI já começa a funcionar. 


Somente quando precisarmos configurar algo específico, é que nos preocupare- 
mos em por algo dentro do arquivo. 


Até agora a estrutura da nossa aplicação está parecida com a da imagem a seguir. 


[© Project Explorer 52 E “= x) beans.xml 52 
v oy livro-cdi 
> A JAX-WS Web Services 
e Ba Deployment Descriptor: livro-cdi 
v 28 java Resources 
> EB src 
> CBtest 
> =) Libraries 
> Es JavaScript Resources 
> © build 
Y (= WebContent 
> © META-INF 
Y © WEB-INF 
&lib 
[IX] beans.xml 
> E Servers 


Design | Source 


Figura 3.2: Estrutura da aplicação e arquivo beans.xml vazio 


3.3 USANDO INJEÇÃO EM PROPRIEDADES, CONSTRUTORES 
E MÉTODOS INICIALIZADORES 


Já sabemos que para injetar um recurso dentro da nossa classe é extramente simples, 
basta fazermos como no exemplo: 


public class CalculadoraDeImpostos ( 
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OInject 
private CalculadoraDeSalarios calculadoraSalarios; 


AERE 


Apesar de ser bastante simples, se lembrarmos que uma das vantagens da 
injeção de dependência é a testabilidade, perceberemos que injetar recursos em 
uma propriedade privada não é nada testável. É só nos lembrar do teste visto 
na seção 2.3, em que nos deparamos com o problema de precisarmos substituir a 
CalculadoraDeSalarios dentroda CalculadoraDeImpostos para que a pri- 
meira devolvesse um valor fixo para a segunda. Mas isso só foi possível quando dei- 
xamos de injetar a dependência dentro de um atributo privado, e passamos a usar o 


construtor. 


@Test 

public void testaCalculoIRNaSegundaFaixaDeContribuicao(){ 
Funcionario funcionario = new Funcionario(); 
funcionario.setSalario(3000.0); // esse método não existe 


CalculadoraDeSalarios calcSalarios = new CalculadoraDeSalarios(); 


CalculadoraDeImpostos calcImpostos = new CalculadoraDeImpostos(); 
calcImpostos.calculadoraSalarios = calcSalarios; //não é possível! 


double impostoDeRenda = 
calcImpostos.calculaImpostoDeRenda(funcionario); 


Assert .assertEquals(129.4, impostoDeRenda, 0.0001); 


Como nesse trecho utilizamos a injeção via propriedade privada, a CDI conse- 
gue injetar, mas nós não. Na verdade é possível, mas teríamos que utilizar recursos 
de programação que saem do que costumamos utilizar no dia a dia. Além disso, 
é totalmente desnecessário fazer essas “maracutaias” uma vez que a CDI consegue 
injetar a dependência de diversas maneiras. 


3.4 ÅS FORMAS DE SE INJETAR DEPENDÊNCIAS 


São três as formas básicas de injetar uma dependência, ou tipos de pontos de injeção, 
e os dois primeiros nós já vimos: via propriedade ou atributo, via construtor, ou via 
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método inicializador. A semântica dessas duas últimas opções é exatamente igual, 
como podemos perceber nos exemplos a seguir. 


public class CalculadoraDeImpostos { 
private CalculadoraDeSalarios calculadoraSalarios; 


OInject 
public void recebe (CalculadoraDeSalarios calcSalarios, 
OutraClasse dependencia2, ...){ 


this.calculadoraSalarios = calcSalarios; 
//obtém outras dependências e pode fazer alguma inicialização 


} 
lark 


Ou então podemos usar o construtor de forma semelhante à do método inicia- 
lizador (nesses exemplos a dependencia2 do tipo OutraClasse tem o intuito 
apenas de mostrar a sintaxe, não fazendo parte do código real). 


public class CalculadoraDeImpostos { 
private CalculadoraDeSalarios calculadoraSalarios; 


OInject 
public Calculadora(CalculadoraDeSalarios calcSalarios, 
OutraClasse dependencia2, ...){ 


this.calculadoraSalarios = calcSalarios; 
//obtém outras dependências e pode fazer alguma inicialização 


} 
[lies 


A vantagem dessas duas abordagens é que podemos utilizar nos nossos testes o 
mesmo método que a CDI usa para injetar as dependências. A diferença das duas 
está apenas no uso ou não de um construtor para injetar as dependências. Se, por 
exemplo, utilizarmos algum framework que utiliza o construtor padrão (público e 
sem argumentos), e optarmos por injetar as dependências usando um construtor, 
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teremos que lembrar de criar manualmente o construtor padrão. Ainda assim, acre- 
dito que essa opção seja mais elegante, como podemos ver no novo código de teste 
a seguir. 


OTest 
public void testaCalculoIRNaSegundaFaixaDeContribuicao ()f 
Funcionario funcionario = new Funcionario(); 


CalculadoraDeSalarios calcSalariosMock = 
new CalculadoraDeSalariosMock(3000.0); 


//cria a CalculadoraDeImpostos passando dependência no construtor 
CalculadoraDeImpostos calcimpostos = 
new CalculadoraDeImpostos (calcSalariosMock) ; 


double impostoDeRenda = 
calcImpostos.calculaImpostoDeRenda(funcionario); 


Assert .assertEquals(129.4, impostoDeRenda, 0.0001); 


Como se observa, voltamos a utilizar o mock criado na seção 2.3 para que o có- 
digo seja executável. Agora vamos ver como fica o código se optarmos pelo método 
inicializador. Nesse caso, não precisaremos criar manualmente o construtor padrão, 
mas a utilização não fica tão limpa: 


//cria a CalculadoraDeImpostos 
CalculadoraDeImpostos calcImpostos = new CalculadoraDeImpostos (); 


//cria o mock 
CalculadoraDeSalarios calcSalariosMock = 
new CalculadoraDeSalariosMock(3000.0); 


//atribui o mock à calculadora de impostos =/ 
calcImpostos.recebe(mock) ; 


Essa abordagem também nos permite passar as dependências dentro de um teste, 
mas a utilização é menos intuitiva. 
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3.5 RECAPITULANDO 


Vimos as três formas de passar uma dependência: via atributo privado, método ini- 
cializador e via construtor. Vimos também que qualquer classe dentro de um pa- 
cote CDI é candidata para satisfazer uma dependência, ou seja, é injetável em outras 
sem precisar de nenhuma configuração ou anotação. Ao contrário, anotamos apenas 
quando queremos que a classe não seja injetável, por padrão todas são. 

Como vimos até aqui, usar a CDI não é nada difícil, é praticamente Java puro. 
Para um projetinho simples, o que vimos até agora já bastaria, pois já sabemos in- 
jetar as dependências, que é uma das principais funcionalidades da CDI. Nos falta 
agora aprender como refinar um pouco mais esse mecanismo, além é claro das outras 
funcionalidades que a especificação nos traz. 

No próximo capítulo veremos como especificar qualificadores às nossas classes, 
evitando casos de ambiguidade. 
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Resolvendo dependências com 
tipagem forte 


Talvez a principal funcionalidade da CDI seja a resolução de dependências de forma 
tipada. Enquanto as primeiras ferramentas de injeção de dependências eram basea- 
das em XML ou em anotações que usavam Strings, a CDI usa a mesma tipagem 
forte que estamos habituados a usar no Java. 

Não injetamos uma dependência baseado no nome de um bean, e sim no seu 
tipo. A utilização de nomes é feita em casos excepcionais, por exemplo, quando 
queremos injetar um objeto de um tipo muito simples, como uma String. 

Como temos muitos casos para analisar, em vez de escrever a teoria da resolução 
de dependências agora, vamos passar pelos exemplos que irão fundamentar o enten- 
dimento dessa teoria. Ao final do capítulo teremos uma revisão do que foi visto e a 
definição do funcionamento desse mecanismo tão importante. 


41. Lidando com a ambiguidade nas dependências Casa do Código 





4.1 LIDANDO COM A AMBIGUIDADE NAS DEPENDÊNCIAS 


Em projetos médios ou grandes, costumamos ter uma diversidade de tipos de com- 
ponentes, diferentes configurações de objetos. É comum termos diversos padrões de 
projetos coexistindo, ainda que não percebidos, algo que geralmente não ocorre em 
projetos pequenos. Esses diferentes arranjos de objetos acabam muitas vezes deman- 
dando uma configuração diferente ao usarmos CDI, mas nada que seja complicado. 

Vamos adotar como exemplo a funcionalidade de cálculo da folha de pagamento 
da nossa empresa. Já vimos na seção 2.3 sobre o princípio da substituição de Liskov, 
e que é uma boa prática o uso de interfaces; logo iniciaremos essa funcionalidade 
pela definição da sua interface. 


public interface CalculadoraFolhaPagamento { 
Folha calculaFolha(List<Funcionario> funcionarios); 


Definimos uma interface bem simples para focarmos na CDI. Para nossa 
CalculadoraFolhaPagamento teremos duas implementações também simples, 
uma que efetua o cálculo efetivo da folha de pagamentos, salvando no banco de da- 
dos a informação da folha do mês corrente; e outra que faz apenas uma simulação, 
não produzindo efeitos permanentes, apenas apurando os valores. 

Partiremos de implementações falsas, que apenas escrevem no console o que 
estariam fazendo: 


public class CalculadoraFolhaPagamentoReal 
implements CalculadoraFolhaPagamento ( 


public Folha calculaFolha(List<Funcionarios> funcionarios)f 


System.out.printiln("Efetua o cálculo " 


+ "real da folha de pagamentos"); 


Apesar da implementação que acabamos de ver, conceitualmente essa imple- 
mentação da CalculadoraFolhaPagamento além de calcular os valores, deixa 
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sempre no banco de dados o resultado do cálculo da folha do mês atual. É possí- 
vel que no mundo real tivéssemos mais métodos nessa interface, possibilitando o 
cálculo retroativo, por exemplo, mas esse método já basta por enquanto. 

Se for a primeira vez que executamos o cálculo dentro do mês, será criado um 
novo registro com os dados da folha desse mês, mas se já tiver um resultado calculado 
no banco, este deverá ser atualizado. Assim sendo, cada mês deve ter apenas um 
registro de cálculo da nossa folha. 


Vamos agora à segunda implementação. 


public class SimuladoraCalculoFolhaPagamento 
implements CalculadoraFolhaPagamento ( 


public Folha calculaFolha(List<Funcionarios> funcionarios)f 


System.out.println("Efetua o simulacao da folha de pagamentos"); 


Já a SimuladoraCalculoFolhaPagamento faz os cálculos dos valores da 
folha sem considerar se há algum registro para o mês, e ao final não salva qualquer 
informação no banco de dados. Serve apenas para o setor financeiro projetar valo- 
res. Seria o equivalente a um simulador de financiamento de um banco. Os valores 
mostrados ali não ficam registrados no sistema do banco, servem apenas como uma 
pré-visualização. 

Agora podemos criar outra servlet para testarmos nossas implementações. Va- 


mos iniciar pela implementação “real”. 


OwebServlet ("/calcular-folha") 
public class CalcularFolhaPagamento extends HttpServlet { 


OInject 
private CalculadoraFolhaPagamento calculadoraFolha; 


public CalcularFolhaPagamento() 1 


System.out.println("Instanciando a Servlet " 
+ " CalcularFolhaPagamento...'"); 
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OPostConstruct 
public void ok(){ 
System.out.println("CalcularFolhaPagamento pronta."); 


protected void doGet (HttpServletRequest req, 
HttpServletResponse res) 
throws ServletException, IOException { 


FuncionarioBuilder builder = new FuncionarioBuilder(); 
Funcionario f1 = builder.comSalarioBaseDe(1000.0).build(); 


builder. comSalarioBaseDe (2000.0).build(); 
builder. comSalarioBaseDe (3000.0).build(); 


Funcionario f2 


ll 


Funcionario f3 
List<Funcionario> funcionarios = Arrays.asList(f1, f2, f3); 
System.out.println("Efetuando o cálculo..."); 

Folha folha = calculadoraFolha.calculaFolha (funcionarios); 


//mensagem para o usuário 
res .getO0utputStream().print("Calculo da folha " 
+ "executado com sucesso"); 


//saída no console 
System.out.println("Fim."); 


O detalhe importante aqui é que não injetamos a implementação, senão não faria 
sentido definirmos a interface. Devemos sempre desenvolver pensando na abstra- 
ção, e não no caso concreto. Sendo assim, solicitamos a injeção de uma implemen- 
tação da interface CalcularFolhaPagamento. Com isso, ao criarmos uma nova 
implementação, não precisamos mudar nossa servlet. 

A não observância dessas boas práticas de projeto de classes é que aumenta o 
efeito cascata quando temos uma mudança no nosso software. Usando a interface, 
se a forma de calcular a folha mudar, não precisamos ficar colando dúzias de ifs para 


56 


Casa do Código Capítulo 4. Resolvendo dependências com tipagem forte 





alterar a classe atual, podemos simplesmente criar uma nova implementação que 
substitui a antiga. 

Podemos ainda rodar as duas implementações em paralelo, algo que não seria 
possível se alterássemos diretamente a implementação original. A menos é claro, 
que fosse feito um imenso if separando o cálculo novo do velho, o que certamente 
transformaria nosso código em algo enorme e cheio de duplicações; difícil de enten- 
der e manter. 

Parece que está tudo certo, mas se executarmos nosso exemplo teremos uma sur- 
presa (o nome totalmente qualificado da classe foi encurtado e a identação alterada 
apenas para simplificar a análise do log): 


org. jboss.weld.exceptions.DeploymentException: 

WELD-001409 Ambiguous dependencies for type [CalculadoraFolhaPagamento] 

with qualifiers [ODefault] at injection point 

[[field] @Inject private br...CalcularFolhaPagamento.calculadoraFolha]. 

Possible dependencies 

[ [Managed Bean 

[class br...CalculadoraFolhaPagamentoReal] 
with qualifiers [@Any ODefault], 


Managed Bean 





[class br...SimuladoraCalculoFolhaPagamento] 
with qualifiers [0Any @Default]]] 


Ao iniciar a aplicação temos essa maravilha de mensagem de erro! Ela nos ex- 
plica certinho o que ocorreu, e onde. Uma das premissas da CDI é tentar adiantar o 
máximo de erros possíveis ao inciarmos seu contexto. Em vez de subirmos a aplica- 
ção com sucesso e encontrarmos diferentes erros a cada tela que acessamos, e pior, 
com mensagens nada explicativas, a CDI define que as validações devem ser feitas 
ao subir o contexto e as mensagens devem dizer o porquê do problema. 

Lendo a mensagem percebemos que a CDI (no caso estamos 
usando a implementação de referência, o Weld) nos mostra exata- 
mente qual o problema. Temos dois candidatos elegíveis para sa- 
tisfazer a dependência no ponto de injeção [[field] @Inject private 
br.com.casadocodigo.livrocdi.servlets.CalcularFolhaPagamento.calculadoraFolha]. 

Se voltarmos à seção 3.4, vamos relembrar os três tipos de ponto de inje- 
ção: atributo (aqui chamado de field), método inicializador e construtor. Na 
mensagem, aparece que a tentativa foi de injetar uma dependência em um 
atributo e ainda mostra qual foi: o atributo calculadorarolha da classe 
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br.com.casadocodigo.livrocdi.servlets.CalcularFolhaPagamento 





Assim, mesmo em uma aplicação grande, não teremos dúvida de onde está o 
problema relatado. 

Continuando a análise da mensagem, veremos que o problema ocorreu porque 
encontramos dois candidatos elegíveis para a mesma dependência, e como não es- 
pecificamos mais nenhum detalhe para ajudar a CDI a escolher, simplesmente foi 
lançada uma exceção. 

Ainda na mensagem de erro vemos que além do tipo, 
CalcularFolhaPagamento, a CDI analisou também os qualifiers, ou quali- 
ficadores das dependências, mas como ambos os candidatos tinham os mesmos 
qualificadores, a ambiguidade permaneceu. 


Nas seções seguintes veremos formas de eliminar essa ambiguidade. 


4.2 Os QUALIFICADORES 


A forma mais comum de eliminar a ambiguidade é através do uso de qualificadores. 
Esse nome, por sinal, é praticamente autoexplicativo. Com qualificadores consegui- 
mos distinguir um candidato a suprir uma dependência de outro. 

A definição de um qualificador é simples, criamos uma anotação que será o qua- 
lificador, e a anotamos para dizer que ela não é uma anotação qualquer. 


import static java.lang.annotation.ElementType.*; 
import java.lang.annotation.Retention; 

import java.lang.annotation.RetentionPolicy; 
import java.lang.annotation.Target; 


import javax.inject.Qualifier; 


OTarget (LTYPE, FIELD, METHOD, PARAMETERJ) 
ORetention(RetentionPolicy.RUNTIME) 
OQualifier 

public Ointerface Simulador { 


} 


Apesar das diversas anotações na nossa anotação, apenas a @Qualifier é da 
CDI, as outras duas são anotações normais do Java. Por isso no código deixei apare- 
cendo os imports. 

As duas primeiras anotações, Target e Retention, servem respectivamente 
para dizer onde poderemos utilizar nosso qualificador, e para que nossa anotação 
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seja legível em tempo de execução, pois sem isso a CDI não conseguiria lê-la. Por 
fim, a anotação que interessa diz que nossa anotação é um qualificador. Agora basta 
qualificarmos nossas classes que não haverá mais dúvidas. 


OSimulador 
public class SimuladoraCalculoFolhaPagamento implements 
CalculadoraFolhaPagamento 1 


//o resto do código permanece igual 


Como nosso qualificador diz que o objeto marcado por ele é um simulador, dei- 
xamos o código real como está, e marcamos apenas o simulador. 

Agora ao subir nossa aplicação não ocorre nenhum erro, e ao executar nossa ser- 
vlet (http://localhost:8080/livro-cdi/calcular-folha) , a saída no console é a seguinte. 


Instanciando a Servlet CalcularFolhaPagamento... 
CalcularFolhaPagamento pronta. 

Efetuando o cálculo... 

Efetua o cálculo real da folha de pagamentos 
Fim. 


Ou seja, a dependência injetada foi a implementação real da 


CalculadoraFolhaPagamento 





Uma coisa que devemos perceber: na nossa servlet pedimos para injetar uma 














CalculadoraFolhaPagamento sem especificar um qualificador, então na prática 
pedimos para que seja injetada uma instância com o qualificador eDefault. 

Se olharmos novamente o log do erro apresentado antes de resolvermos a am- 
biguidade, aparecia a mensagem de que foram encontrados dois candidatos com os 
tipos compatíveis, e com os mesmos qualificadores, @QAny e Default. 

Logo, podemos concluir que assim como quando não especificamos nenhum 
construtor na nossa classe o Java automaticamente cria um construtor default, assim 
também a CDI qualifica nossos objetos com o qualificador default se não especifi- 
carmos outro. 

Podemos concluir também que se anotarmos a classe 
CalculadoraFolhaPagamentoReal com o qualificador @Simulador, 
voltaremos a ter o mesmo problema de ambiguidade, mas dessa vez com os 
qualificadores Any e ESimulador. 
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Qualificadores com atributos 


Como sempre, agora que entendemos a solução, vamos evoluir um pouquinho 
o problema. Vamos supor que está sendo feito um estudo de viabilidade financeira 
de um novo plano de cargos para a empresa, e já que temos a funcionalidade de 
simular a folha de pagamento, o setor financeiro nos pediu para implementarmos 
um simulador que considerasse os parâmetros pretendidos no novo plano. 

Dessa forma, a implementação real e sua servlet permanecem inalteradas, mas 
precisaremos de mais uma instância de CalculadoraFolhaPagamento para exe- 
cutar essa nova tarefa. O detalhe é que essa nova implementação também será um 
simulador, mas em vez de simular no plano de cargos atual, que é do ano de 2005, 
vai fazer os cálculos baseados na proposta de 2013. 

Como resolvemos? Alteramos nosso qualificador para ESimulador2005 e cri- 
amos um ESimulador2013? Já considerando essas situações — os qualificadores 
— assim como qualquer anotação Java pode ter atributos, no nosso vamos criar um 
que servirá para identificar o plano que está sendo considerado. 


OTarget (LTYPE, FIELD, METHOD, PARAMETERJ) 
ORetention(RetentionPolicy.RUNTIME) 
OQualifier 
public Ointerface Simulador { 
PlanoDeCargos planoDeCargos() default PlanoDeCargos.VERSAO 2005; 


Alteramos nosso qualificador para que ele aceite a indicação do plano de car- 
gos que está sendo considerado. Para manter a compatibilidade, especificamos 
que caso não seja especificado um valor para essa propriedade, será conside- 
rado o plano de 2005, mas poderíamos deixar sem valor padrão e alterar nossa 
SimuladoraCalculoFolhaPagamento para especificar lá qual plano usar. Mas 
como em um caso real pode ser que tenhamos muito mais casos para mudar, dessa 
maneira minimizamos os impactos. 

Outra coisa que podemos perceber é que estamos usando uma enum que repre- 
senta os planos de cargos. 


public enum PlanoDeCargos { 
VERSAO 2005, VERSAO 2013 


É um código bem simples, que estamos usando apenas para não usarmos um 
inteiro puro, pois isso pode acarretar erro de digitação. E o enum tem ainda a vanta- 
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gem de trazer os valores possíveis prontos, enquanto se estivéssemos usando inteiro, 
além da possibilidade do erro de digitação, teríamos que saber de cabeça quais os 
valores válidos. 

Agora sim, podemos criar o novo simulador especificando a versão do plano que 


estamos considerando. 


import static 
br.com.casadocodigo.livrocdi.qualificadores.PlanoDeCargos.*; 


CSimulador (planoDeCargos = VERSAO 2013) 
public class SimuladoraCalculoFolhaPagamentoPlano2013 implements 
CalculadoraFolhaPagamento { 


QOverride 

public Folha calculaFolha(List<Funcionario> funcionarios) { 
System.out.printin("Simulação com plano de 2013"); 
return null; 


A diferença está apenas no fato de especificarmos um valor diferente do 
padrão dentro do nosso qualificador. Agora quando formos injetar uma 
CalculadoraFolhaPagamento dentro de um bean, temos as seguintes opções: 


OInject 
private CalculadoraFolhaPagamento calculadoraFolha; 


Isso injeta a implementação real da interface pedida, que será um objeto da classe 
CalculadoraFolhaPagamentoReal. Na prática é como se estivéssemos especi- 
ficando que queremos o qualificador GDefault. 


OInject CSimulador 
private CalculadoraFolhaPagamento calculadoraFolha; 


//ou 


CInject OSimulador (planoDeCargos = VERSAO 2005) 
private CalculadoraFolhaPagamento calculadoraFolha; 
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Como especificamos a VERSAO 2005 como valor padrão do qualifica- 
dor, essas duas opções são equivalentes, e a implementação injetada será a 
SimuladoraCalculoFolhaPagamento 


Por fim, temos a seguinte opção. 


OInject OSimulador (planoDeCargos = VERSAO 2013) 
private CalculadoraFolhaPagamento calculadoraFolha; 


Isso fará com que o bean injetado seja da classe 
SimuladoraCalculoFolhaPagamentoPlano2013. 

A utilização de propriedades nos qualificadores é uma ferramenta interes- 
sante pois evita a criação de qualificadores esquisitos, que seriam na verdade 
uma especialização de outro qualificador. Em vez de termos dois qualificadores: 
ESimulador2005 e GSimulador2013, temos apenas um qualificador no qual 
podemos especificar um atributo. 


Podemos ter inclusive vários atributos dentro do nosso qualificador: 


import javax.enterprise.util.Nonbinding; 


OTarget (LTYPE, FIELD, METHOD, PARAMETER)) 
ORetention(RetentionPolicy.RUNTIME) 
OQualifier 
public Ointerface Simulador { 
PlanoDeCargos planoDeCargos() default PlanoDeCargos.VERSAO 2005; 
boolean planoAprovado() default true; 
CNonbinding boolean enviarNotificacao() default false; 


Para mostrar como podemos utilizar mais de uma propriedade, alteramos nosso 
qualificador para que ele receba mais de uma propriedade. Nesse exemplo, adiciona- 
mos duas novas propriedades. A primeira para definir se o simulador é de um plano 
já aprovado ou não, e a segunda é apenas uma informação extra, que não influencia 
na qualificação propriamente dita. 

Isso porque anotamos a propriedade enviarNotificacao com 
ENonbinding, e dessa maneira informamos à CDI que a mesma não deve 
ser considerada quando um bean candidato estiver sendo escolhido. O valor aí 
presente serve apenas como uma propriedade informativa para o nosso código 
Java. Ou seja, em algum momento podemos ter um código analisando se o valor 
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da propriedade é verdadeiro para enviar, por exemplo, um e-mail avisando que o 
cálculo foi realizado e qual o resultado. 

Apesar das propriedade nos qualificadores evitar a criação de novos qualifica- 
dores de maneira desnecessária, existirão casos em que teremos mais de um quali- 
ficador ao mesmo tempo. Cada qualificador desses pode ter atributos que especifi- 
cam ainda mais o que queremos, que são os atributos que não estão anotados com 
ENonbinding, e também atributos que possuam essa anotação e servem apenas 
como informação adicional. 

É só lembrar que Nonbinding significa “não vinculante” aquele que não cria vín- 
culo. Fora essas propriedades não vinculantes, todas as outras refinam mais ainda 
a qualificação do bean — assim também como acontece quando temos mais de um 
qualificador. 

Ao final do capítulo, na seção 4.9, teremos uma recapitulação de todo o processo 
de resolução de dependências envolvendo qualificadores e outras ferramentas que 
veremos até lá. Tente imaginar as possibilidades com as ferramentas que você já viu, 
e se permanecer alguma dúvida, com o resumo acredito que ela será sanada. 


O qualificador & Any 


Já entendemos como acabar com uma ambiguidade através de um qualificador, 
mas nos deparamos algumas vezes com esse qualificador @Any. Como o nome dele 
diz, esse qualificador está presente em qualquer objeto. 

Para exemplificar, vamos mudar nossa servlet, que está funcionando sem qual- 
quer ambiguidade, para que ela fique dessa forma: 


OwebServlet ("/calcular-folha") 
public class CalcularFolhaPagamento extends HttpServlet { 


OInject @Any 
private CalculadoraFolhaPagamento calculadoraFolha; 


//o restante permanece igual 


} 

Sabemos que temos três candidatos a satisfazer de- 
pendências do tipo CalculadoraFolhaPagamento, que 
são: CalculadoraFolhaPagamentoReal, que está com 
o qualificador @Default, já que não especificamos outro, 
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SimuladoraCalculoFolhaPagamento, o qual recebeu o qualificador 
eSimulador, e SimuladoraCalculoFolhaPagamentoPlano2013, que 





recebeu o qualificador Simulador (planoDeCargos = VERSAO 2013). 

Se no ponto de injeção não colocarmos nenhum qualificador, estaremos impli- 
citamente pedindo o default, e se colocarmos ESimulador sabemos qual instância 
será injetada também. Mas fazendo a alteração que acabamos de ver, estamos pe- 
dindo para que nesse caso seja considerado qualquer candidato disponível no con- 
texto. 

No nosso exemplo, isso fará com que voltemos a ter problemas de ambiguidade: 


org. jboss.weld.exceptions.DeploymentException: WELD-001409 
Ambiguous dependencies for type [CalculadoraFolhaPagamento] 

with qualifiers [0Any] at injection point [[BackedAnnotatedField] 
CInject @Any private br...CalcularFolhaPagamento.calculadoraFolha]. 
Possible dependencies 

[[Managed Bean [class br...SimuladoraCalculoFolhaPagamentoPlano2013] 
with qualifiers [OSimulador @Any], 

Managed Bean [class br...SimuladoraCalculoFolhaPagamento] 

with qualifiers [OSimulador @Any], 

Managed Bean [class br...CalculadoraFolhaPagamentoReal] 

with qualifiers [@Any @Default]]]. 

Please see server.log for more details. 


Para que serviria então esse qualificador? Fle, na verdade, seria o equivalente à 
classe java.lang.Object, que é mãe de qualquer objeto Java, mas para os objetos 
que estão no contexto CDI. Assim, se precisarmos, por algum motivo, buscar todos 
os candidatos de um determinado tipo, independente de qualificadores, usamos o 
qualificador especial @Any. 

O uso ficará mais claro quando estivermos estudando a busca programática de 
dependências, na seção 4.8. Nesse cenário será interessante podermos buscar todos 
os candidatos a satisfazer uma dependência de um determinado tipo, e então tomar 
alguma decisão em tempo de execução, ou ainda usar todos esses objetos de uma 
vez. 

Apenas para não ficar muito abstrato, vamos supor que tenhamos uma interface 
que define um mecanismo de notificação. Essas notificações seriam enviadas ao res- 
ponsável pelo setor financeiro da empresa sempre que uma nova folha fosse gerada, 
podendo ser por e-mail, SMS ou qualquer meio que possamos imaginar. 

Como não sabemos quais qualificadores as implementações dessa interface po- 
dem ter, podemos utilizar o qualificador @Any para buscar todas as implementações 
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disponíveis, colocá-las em uma Collection, e então passar por todas as instân- 
cias invocando uma a uma para garantir que por algum meio a notificação chegaria 
a quem interessar. 


4.3 ALTERNATIVES: ELIMINANDO AMBIGUIDADE E TOR- 
NANDO UM BEAN OPCIONAL 


A anotação Alternative serve para transformarmos um bean em uma alterna- 
tiva a suprir uma dependência, ou seja, ele não será um candidato automaticamente 
disponível. 

Todo bean alternativo só é injetável se for declarado no beans.xmi, e nesse 
caso ele fica com uma prioridade maior do que o bean não alternativo. 

No caso da aplicação que estamos desenvolvendo, vamos considerar que tivemos 
a criação de um novo plano de cargos e salários, que alterou totalmente a forma como 
nosso cálculo de salário é feito hoje. A primeira alternativa que podemos pensar é 
em alterar a classe CalculadoraDeSalarios para acomodar as novas regras, mas 
vamos analisar melhor esse caso. 

Uma mudança grande assim pode não entrar em vigor imediatamente, então 
vamos considerar que a mudança entre em produção daqui três meses. Além disso, 
após entrar em produção pode ser que por descontentamento de alguns, a empresa 
volte atrás, para a regra que estava funcionando antes e parta para a elaboração de 
um novo plano. 

Alterando diretamente o código da CalculadoraDeSalarios, não podería- 
mos colocar em produção imediatamente pois a regra nova só passaria a valer no 
futuro. E depois se tivermos que voltar a regra antiga teríamos que reverter as alte- 
rações. Apesar desses cenários serem bem cobertos por um bom uso de controle de 
versão de código, caso isso não seja feito corretamente, e não tenhamos um servidor 
de build, podemos ter situações em que não seria possível determinado desenvolve- 
dor fazer um novo deploy pois a versão que está na sua máquina já está com o cálculo 
alterado. Claro que esse é um exemplo praticamente lúdico, mas não quer dizer que 
não ocorra. 

Um dos usos de GAlternative pode ser justamente o desenvolvimento dessa 
nova versão da CalculadoraDeSalarios. Em vez de mudar a implementação 
da classe, extraímos uma interface dessa classe (geralmente as IDEs tem atalhos para 
fazer isso). Dessa forma teremos a interface CalculadoraDeSalarios ea imple- 
mentação com o código atual, e todos os pontos de injeção devem continuar apon- 
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tando para o tipo CalculadoraDeSalarios, que antes era uma classe, e agora 
passa a ser uma interface. 


public interface CalculadoraDeSalarios { 


double calculaSalario(Funcionario funcionario); 


public class CalculadoraDeSalariosPlano2005 
implements CalculadoraDeSalarios { 
/* 
Código igual ao que tínhamos em 
CalculadoraDeSalarios quando era classe 


*/ 


Agora como estamos criando um novo cálculo com base no novo plano de sa- 
lários, basta criarmos uma nova implementação, que pode por exemplo se cha- 
mar CalculadoraDeSalariosPlano2013, para indicar que é o cálculo do plano 
criado nesse ano. Porém se colocarmos as duas implementações em produção ao 
mesmo tempo, teremos o já conhecido problema da ambiguidade. Por isso, na nova 
implementação utilizaremos a anotação GAlternative. 


import javax.enterprise.inject.Alternative; 


OAlternative 
public class CalculadoraDeSalariosPlano2013 
implements CalculadoraDeSalarios 1 


//o novo código, que nesse exemplo não influencia no entendimento 
QOverride 
public double calculaSalario (Funcionario funcionario)( 

return 0.0; 


Agora podemos deixar a implementação pronta, e inclusive fazer um deploy com 
ela sem o menor problema, pois os beans alternativos não são injetáveis em lugar ne- 
nhum até segunda ordem. Essa segunda ordem será a expressa habilitação desse bean 
no arquivo beans .xm1, ou via anotação, momento em que ele passa a ser elegível e 
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inclusive “sobrescreve” o bean não alternativo. Em outras palavras, quando ligarmos 
a CalculadoraDeSalariosPlano2013, ela entra automaticamente no lugar da 
CalculadoraDeSalariosPlano2005. E caso seja necessário voltar atrás, basta 
comentar a linha do arquivo beans . xml onde habilitamos o bean. 

Pela primeira vez estamos mexendo com um arquivo xml, e ainda assim seu có- 
digo é mínimo. A grande maioria dele é o cabeçalho do arquivo, e eu encurtei o 
nome da classe para ficar bem em uma linha, mas sempre que usarmos o arquivo 
xml, deve usar o nome totalmente qualificado das classes. 


<beans xmlns="http://xmlns.jcp.org/xml/ns/javaee" 
xmins:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee 
http://xmlns.jcp.org/xml/ns/javaee/beans 1 1.xsd"> 
<alternatives> 
<class> 
br.com.casadocodigo...CalculadoraDeSalariosPlano2013 
</class> 
</alternatives> 
</beans> 


Agora, ao executarmos nosso sistema, a classe 
CalculadoraDeSalariosPlano2013 é que será a injetável nos pontos que 
pedem pela interface CalculadoraDeSalarios. 

Podemos perceber que o uso de GAlternative tem um propósito diferente do 
uso dos qualificadores vistos antes, é uma forma de desabilitar temporariamente um 
bean, e habilitá-lo em momento oportuno de uma forma que ele volte no lugar do 
bean equivalente. 

Em um cenário mais complexo, podemos ter até mais de um bean marcado como 
alternativo. Por exemplo, quando utilizamos o padrão Strategy. É possível marcar 
todas as implementações como alternativas e habilitar somente aquela que queremos 
usar no momento. Porém, se habilitarmos mais de uma, voltaremos ao problema 
da ambiguidade, a menos que especifiquemos, via anotação, qual alternativa tem 
prioridade maior. 
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4.4 PRIORIDADE: NOVIDADE DA CDI 1.1, PARTE DO JAVA EE 
7 


A partir do Java EE 7, com a atualização da especificação de interceptor para a versão 
1.2 (JSR 318 release de manutenção 2), foi adicionada a possibilidade de estipularmos 
ordenação dos interceptors; para que isso fosse possível, foi adicionada a anotação 
@Priority nas anotações comuns do Java (JSR 250). Quando estivermos estudando 
os interceptadores, veremos mais sobre isso. Por enquanto vamos analisar essa ano- 
tação do ponto de vista dos GAlternatives. 

Como já vimos, usar alternativas é uma boa forma de criarmos diferentes opções 
para uma dependência, mas até o Java EE 6, não conseguíamos habilitar mais de uma 
alternativa ao mesmo tempo, pois teríamos o problema de ambiguidade. Um bean 
alternativo tem prioridade sobre um bean não alternativo, mas entre os alternativos 
não havia maneira de estipular prioridade. 

Agora, além de não precisarmos mais utilizar o arquivo beans .xm1 para ati- 
var uma alternativa, podemos estipular diferentes prioridades para cada uma, assim, 
será injetada a de prioridade maior. 

A anotação GPriority requer um inteiro que especifica qual a prioridade, e 
será injetado o bean de prioridade maior. Não é obrigatório, mas é interessante uti- 
lizarmos o intervalo de valores que constam na especificação de interceptors: 


e Interceptor.Priority. PLATFORM BEFORE = o 


e Interceptor.Priority. LIBRARY. BEFORE = 1000 


Interceptor.Priority. APPLICATION = 2000 


Interceptor.Priority. LIBRARY AFTER = 3000 


Interceptor.Priority. PLATFORM. AFTER = 4000 


Os valores para plataforma e biblioteca servem para especificar respectivamente 
os intervalos que são usados pela plataforma Java, ou seja, as partes do próprio Java 
EE; e para serem usados pelas bibliotecas, frameworks, e outras coisas que executam 
em momento diferente da plataforma, e também da nossa aplicação. 

Como estamos aqui tratando do desenvolvimento de aplicações, vamos trabalhar 
a partir do valor Interceptor.Priority.APPLICATION. Vamos então alterar 
nossas implementações de CalculadoraDeSalarios apenas para vermos essa 


possibilidade. 
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import javax.annotation.Priority; 
import javax.enterprise.inject.Alternative; 
import javax.interceptor. Interceptor; 


OAlternative OPriority(Interceptor.Priority.APPLICATION + 1) 
public class CalculadoraDeSalariosPlano2013 
implements CalculadoraDeSalarios 1 


// código permanece igual 


Vamos anotar nossa classe CalculadoraDeSalariosPlano2013 comaano- 
tação GPriority e informar a prioridade que queremos. Agora podemos comentar 
no beans.xml onde ativávamos esse bean alternativo, pois a anotação supre essa 
demanda. 


<beans xmlns="http://xmlns.jcp.org/xml/ns/javaee" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee 
http://xmlns.jcp.org/xml/ns/javaee/beans 1 1.xsd"> 
<alternatives> 
<l-- 
<class> 
br.com.casadocodigo...CalculadoraDeSalariosPlano2013 
</class> 
sa» 
</alternatives> 
</beans> 


Vamos agora deixar nossa implementação atual também como alternativa para 
podermos testar a priorização. 


import javax.annotation.Priority; 
import javax.enterprise.inject.Alternative; 
import javax.interceptor. Interceptor; 


OAlternative OPriority(Interceptor.Priority.APPLICATION) 


public class CalculadoraDeSalariosPlano2005 
implements CalculadoraDeSalarios 1 
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// código permanece igual 


Notem que a CalculadoraDeSalariosPlano2013 ficou com uma priori- 
dade maior para que ela seja a escolhida. 

Para conseguirmos testar, podemos criar uma outra servlet que injeta essa de- 
pendência e simplesmente escrever a classe selecionada na resposta para o usuário. 
Em breve, estaremos melhorando essa forma de testar e a apresentação para o usuá- 
rio, mas para darmos um passo de cada vez, ainda está mais simples fazer isso usando 
servlets auxiliares. 


CwWebServlet ("/calcular-salario") 
public class CalculadoraSalario extends HttpServlet { 


OInject 
private CalculadoraDeSalarios calculadoraDeSalarios; 


QOverride 
protected void doGet (HttpServletRequest reg, HttpServletResponse res) 
throws ServletException, IOException { 


res.getOutputStream() 
.print("Calculadora: " + calculadoraDeSalarios.getClass()); 


Aí basta alternarmos a prioridade de uma ou outra instância de 
CalculadoraDeSalarios e executar novamente para percebermos a mu- 
dança na seleção do bean a ser injetado. 


4.5 BEANS NOMEADOS 


Apesar da CDI trabalhar muito bem com a resolução de dependências através de 
tipos, há casos em que precisamos que um bean seja descoberto a partir de um nome. 
Isso pode ser necessário quando pedimos a injeção de um tipo muito simples, como 
uma Stringouum Integer que signifique, por exemplo, o caminho padrão onde 
anexos serão salvos ou o número máximo de elementos a ser exibidos nas páginas 
de listagem do sistema, ou seja, nas paginações. 
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CInject ONamed("caminhoSalvarAnexos") 
private String caminhoAnexos; 


CInject ONamed("tamanhoPaginacao") 
private Integer tamanhoPaginacao; 


Nesse caso, como o tipo é muito comum, usamos o nome como um qualifica- 
dor. Mas de onde virão esses objetos? Esses tipos são do próprio Java, logo, não são 
injetáveis diretamente, ainda mais com esses nomes. Para suprir essa necessidade, a 
CDI define os métodos produtores, que serão apresentados na seção 5.1, então não 
se preocupe com esse detalhe ainda. 

Uma outra forma de recuperarmos essas informações que estamos pedindo via 
nome, seria através da definição de um tipo que represente as configurações do sis- 
tema. Nesse tipo perderíamos colocar essas e demais informações necessárias, como 
caminhos de wsdl para integração entre sistemas e o que mais for necessário. Po- 
deríamos em um método produtor buscar essas informações no banco de dados e 
colocar o objeto com todas as informações no contexto CDI. Assim, em vez de bus- 
car uma informação no banco cada vez que precisássemos, bastaria injetar o objeto 
que representa a configuração do sistema. 

Mas se a funcionalidade de nomearmos um bean servisse somente para 
isso, acabaríamos de descobrir que ela na verdade não é muito útil. Po- 
rém temos um caso em que os nomes são necessários, e dessa vez não te- 
mos como fazer de outra forma. Esse caso é a utilização dos beans em expres- 
sion languages, ou ELs. Por exemplo, em uma página JSP ou JSF onde temos 


t(calculadoraFolhaBean.ultimoCalculo.valorFolha). 





Quando trabalhamos com EL, temos apenas uma String que representa o 





nome do bean, no caso o calculadoraFolhaBean. Logo, a resolução desse 
objeto precisará ser feita via nome. Para que um bean seja alcançável por EL, 
precisamos “batizá-lo dar um nome a ele. Para isso utilizamos a anotação 


javax.inject. Named 


import javax.inject.Named; 


ONamed 
public class CalculadoraFolhaBean { 


//precisa ter um método getter 
private FolhaPagamento ultimoCalculo; 
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Nessa anotação podemos especificar um nome, como 
ENamed ("nomeDoBean"), ou podemos deixar o nome padrão como no exem- 
plo. Esse nome padrão nada mais é do que o nome simples da classe com a 
primeira letra passada para minúsculo. Por isso, na EL vista antes usávamos 
calculadoraFolhaBean. 

Uma vez resolvido o objeto raiz da EL, que precisa ter um nome, os demais são 
alcançados via reflection, através dos respectivos getters em caso de leitura, e setters 
em caso de escrita. Esse funcionamento, porém, será visto em outro momento, pois o 
importante nessa seção é entendermos que além da resolução por tipo, a CDI suporta 
resolução por nome. 

O mais comum é utilizarmos os beans nomeados como objeto raiz em uma EL, 
mas nada impede que o injetemos em outro bean; e nesse caso pode ser tanto por 
nome, como pelo tipo, como já estamos habituados. 


4.6 TRABALHANDO COM HERANÇA ENTRE BEANS 


Já vimos sobre princípio da substituição na seção 2.3; no ponto de vista do Java, se 
estivermos usando interfaces, conseguimos trocar suas implementações ou conse- 
guimos trocar um tipo por seus subtipos. Usando CDI, no entanto, não basta usar 
implements ou extends. 

Vamos tomar como exemplo a classe CalculadoraDeSalariosPlano2013, 
que já vimos nos exemplos anteriores, e uma nova classe que veremos agora, a 





CalculadoraAssincronaDeSalariosPlano2013. O código dessas classes não 
importam para nosso exemplo, o importante é entendermos como aplicar a substi- 
tuição entre a calculadora e a calculadora assíncrona, seu subtipo. 


GCalculadora 
public class CalculadoraDeSalariosPlano2013 
implements CalculadoraDeSalarios 


Para enriquecer nossa análise, adicionamos um qualificador novo, que usaremos 
apenas nesse exemplo: ECalculadora. Agora vejamos a calculadora assíncrona. 


OAlternative OPriority(Interceptor.Priority.APPLICATION) 
public class CalculadoraAssincronaDeSalariosPlano2013 
extends CalculadoraDeSalariosPlano2013 {} 
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Para que não tenhamos problemas de ambiguidade, vamos considerar, 
para o estudo de herança, que a CalculadoraDeSalariosPlano2013 é 
uma classe simples (e não um (Alternative como vimos antes) e que a 
CalculadoraAssincronaDeSalariosPlano2013 é um bean alternativo ativo, 
pois está anotado com GPriority. Esse ajuste é apenas para termos um cenário 
mais simples de analisar, porém com todos os ingredientes para uma boa análise 
desse tema. 

Com base no que já sabemos, conseguimos predizer como a CDl irá resolver a 
seguinte dependência. 


OInject 
private CalculadoraDeSalarios calculadora; 


Como ambas as classes que acabamos de ver são de tipo compatível com a inter- 
face solicitada, mas como a CalculadoraAssincronaDeSalariosPlano2013 
é alternativa, ou seja, tem prioridade, sabemos que ela será a implementação seleci- 
onada. Mas qual seria o resultado se o trecho que solicita a injeção da dependência 
fosse como o seguinte: 


OInject OCalculadora 
private CalculadoraDeSalarios calculadora; 


Nesse caso, seria injetada uma instância da classe 
CalculadoraDeSalariosPlano2013, pois sua subclasse não possui o quali- 
ficador @Calculadora. No entanto, por mais que não tenhamos analisado o 
código da classe CalculadoraAssincronaDeSalariosPlano2013, vamos 
considerar que ela é uma evolução de sua classe mãe, e que, ao criá-la, esperávamos 
que ela entrasse no lugar da classe mãe. Até porque, já estudamos o princípio da 
substituição e sabemos que é possível, mas como nos assegurar que a nova classe 
sempre será selecionada no lugar da antiga? 

Uma forma de fazer isso seria, além de estender a classe original, colocar na sub- 
classe todos os qualificadores da primeira. Com isso, no exemplo que acabamos de 
ver, em que além do tipo eram pedidos qualificadores (no caso um, mas poderiam 
ser diversos), o bean selecionado seria a calculadora assíncrona. Mesmo assim ainda 
teríamos dois casos em que a classe mãe continuaria sendo utilizada: métodos pro- 
dutores e observadores de eventos. Esses dois assuntos ainda não foram vistos, mas 
o que importa por enquanto é que ambos não são herdados pela subclasse. 
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A anotação ESpecializes 


Para resolver essa questão, a CDI disponibiliza a anotação ESpecializes, que 
marca a subclasse como uma substituta da classe mãe. Assim, mesmo que a nova 
implementação seja adicionada em um novo jar, muito tempo depois que o sistema 
está em produção, ela certamente entrará em todos os lugares onde a classe mãe era 
utilizada. Para tal, basta colocar essa anotação na classe filha. 


OSpecializes 0Assincrono 
public class CalculadoraAssincronaDeSalariosPlano2013 
extends CalculadoraDeSalariosPlano2013 {} 


Agora sabemos que o novo bean substituirá totalmente o antigo, pois ao usar 
@Specializes a classe filha herda também todos os qualificadores da mãe. Isso 
não impede no entanto que a nova classe defina novos qualificadores, como o 
GAssincrono do exemplo. 

Outra coisa herdada é o nome do bean original. Caso a classe mãe possui o 
qualificador @Namea, a classe filha necessariamente herdará o mesmo nome. Se a 
classe mãe não possuir um nome, a filha fica livre para definir ou não um. Mas se 
a mãe for nomeada e a filha tentar definir um novo nome, será lançado um erro 
quando a configuração for lida enquanto a aplicação inicializa. 

Porém, nem tudo é tão automático, como o mecanismo de especialização precisa 
garantir que realmente a classe mãe não será instanciada em momento algum pela 
CDI, e como os métodos produtores e observadores de eventos não são herdados, 
os mesmos ficarão inativos a menos que sejam reimplementados (sobrescritos) na 
subclasse. 


4.7 RESTRINGINDO O TIPO DOS BEANS 


Já vimos diversas formas de lidar com ambiguidade entre beans: qualificadores, al- 
ternatives, e até especializar um bean. Mas temos ainda outra forma de gerenciar 
nossas dependências, que é forçando o tipo do bean. Obviamente não podemos co- 
locar qualquer tipo que queiramos, mas apenas limitar até que nível da hierarquia 
nosso bean estará apto a responder. 

Vamos recapitular alguns dos exemplos que vimos até aqui, e verificar uma nova 
forma de lidar com a ambiguidade. 


public interface CalculadoraDeSalarios ( ... } 
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public class CalculadoraDeSalariosPlano2013 
implements CalculadoraDeSalarios { ... + 


public class CalculadoraAssincronaDeSalariosPlano2013 
extends CalculadoraDeSalariosPlano2013 { ... } 


Como já vimos até agora, a resolução de dependências da CDI é fortemente base- 
ada em tipos, então esse é o fator determinante na escolha de um desses candidatos. 
Vamos ver os próximos exemplos. 


//problema de ambiguidade 
OInject private CalculadoraDeSalarios calculadora; 


//problema de ambiguidade 
OInject private CalculadoraDeSalariosPlano2013 calculadora; 


//sem problema de ambiguidade 
OInject private CalculadoraAssincronaDeSalariosPlano2013 calculadora; 


Os problemas de ambiguidade que acabamos de 
ver envolvem CalculadoraDeSalariosPlano2013 e 
CalculadoraAssincronaDeSalariosPlano2013. Isso porque natural- 


mente cada bean é candidato a suprir dependências de qualquer um dos tipos 
do bean. No caso, CalculadoraAssincronaDeSalariosPlano2013 res- 
ponde pelo próprio tipo, por CalculadoraDeSalariosPlano2013, por 
CalculadoraDeSalarios epor java.lang.Object. Mas podemos restringir 
por quais tipos nosso bean está disposto a responder, para isso basta usarmos a 


anotação Qjavax.enterprise.inject.Typed. 


//responde apenas por CalculadoraDeSalarios e Object 

OTyped(CalculadoraDeSalarios.class) 

public class CalculadoraAssincronaDeSalariosPlano2013 
extends CalculadoraDeSalariosPlano2013 { ... 5 


/* 
responde por CalculadoraDeSalarios, 
CalculadoraDeSalariosPlano2013 e Object 
*/ 
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OTyped((CalculadoraDeSalarios.class, 
CalculadoraDeSalariosPlano2013.class)) 

public class CalculadoraAssincronaDeSalariosPlano2013 
extends CalculadoraDeSalariosPlano2013 1 ... 5 


Restringir o tipo de um bean pode, em determinada situação, re- 





solver um problema de ambiguidade. Por exemplo, se injetarmos o 
tipo CalculadoraDeSalariosPlano2013 e restringirmos o tipo 
de CalculadoraAssincronaDeSalariosPlano2013 para o tipo 
CalculadoraDeSalarios. Nesse caso apenas o próprio bean do tipo 














CalculadoraDeSalariosPlano2013 poderá se candidatar. 
Essa talvez não seja a forma mais habitual de lidar com ambiguidade, mas é mais 
uma ferramenta que a CDI nos oferece. 


4.8 RESOLUÇÃO DE DEPENDÊNCIA SOB DEMANDA E LOO- 
KUP PROGRAMÁTICO 


Há situações em que a injeção de dependência comum não é o bastante. Podemos ter 
problemas de dependência cíclica, ou problemas de lentidão quando um bean tem 
muitas dependências, que por sua vez pode ter também várias outras dependências. 
Para solucionar esse problema podemos lançar mão da injeção de dependência lazy, 
ou sob demanda. 

Para exemplificar, vamos tomar como exemplo a injeção de uma instância de 


CalculadoraFolhaPagamento, 


//forma tradicional 
OInject 
private CalculadoraFolhaPagamento calculadoraFolhaPagamentoPadrao; 


//injeção sob demanda 

OInject 

private Instance<CalculadoraFolhaPagamento> 
calculadoraFolhaPagamentoLazy ; 


Nesses exemplos, conforme já vimos, teremos a injeção de uma 


instância da implementação CalculadoraFolhaPagamentoReal. 
Isso porque usamos o qualificador Default, e as demais 
implementações, SimuladoraCalculoFolhaPagamento e 
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SimuladoraCalculoFolhaPagamentoPlano2013, possuem o qualifica- 
dor ESimulador. 

A diferença é que ao injetarmos da forma tradicional, a instância é imediata- 
mente criada - ou recuperada, dependendo do escopo -, enquanto a forma lazy é 
apenas um link para o tipo pretendido. A instância real é disponibilizada através do 
método get (), como vemos a seguir. 


OInject 
private Instance<CalculadoraFolhaPagamento> 
calculadoraFolhaPagamentoLazy ; 


CalculadoraFolhaPagamento calculadora = 
calculadoraFolhaPagamentoLazy.get(); 


Somente nesse momento a instanciação acontece. Essa abordagem ajuda em ca- 
sos de injeção lenta. Caso tenhamos muitas dependências que são utilizadas somente 
em determinados casos, por exemplo dependendo de alguma informação externa, 
pedir para todas as dependências serem resolvidas desde o início poderá provocar 
uma certa lentidão no sistema. 

Em cenários assim, é bem possível que esse bean esteja pouco coeso, fazendo 
coisas diferentes, coisas demais. Porém quando trabalhamos com instanciação ma- 
nual das dependências, acabamos instanciando cada dependência só quando elas são 
demandadas, o que acaba maquiando o que talvez seja um problema de projeto das 
classes. 

Porém sabemos que nem sempre é simples fazer alguns ajustes na aplicação, 
como por exemplo separar beans muito grandes em outros mais coesos, se esse for 
o caso, ainda será possível usar a instanciação sob demanda para melhorar a per- 


formance. Usando a interface javax.enterprise. inject. Instance, criamos 





um ponteiro que não cria a instância imediatamente, mas no permite fazer no mo- 
mento apropriado, assim como faríamos se tivéssemos instanciando todas as classes 
manualmente. O mesmo pode ser usado para evitar os problemas de dependência 
cíclica, que também pode significar um problema de projeto que só aparece quando 
passamos a utilizar uma gestão de dependência automática. 


Lookup programático 


Como falamos quando vimos o qualificador @Any, ele será muito útil agora 
quando vamos, programaticamente, buscar as dependências da nossa aplicação. 
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Através desse qualificador conseguiremos recuperar todas as instâncias candidatas, 
como podemos ver a seguir. 


//forma tradicional lança exceção 
OInject @Any 
private CalculadoraFolhaPagamento todasCalculadorasFolhaPagamento ; 


//injeção sob demanda 
OInject CAny 
private Instance<CalculadoraFolhaPagamento> todasCalculadorasFolhaLazy; 


Enquanto na forma tradicional nós teríamos uma exceção ao tentar injetar 
CalculadoraFolhaPagamento usando o qualificador @Any, na injeção sob de- 
manda só teríamos a exceção se chamássemos o método get (). Mas aqui vai entrar 
o dinamismo de descobrirmos a instância correta para o momento. 


OInject CAny 
private Instance<CalculadoraFolhaPagamento> todasCalculadoras; 


if (simulacao)1 


Instance<CalculadoraFolhaPagamento> simuladoras = 
todasCalculadoras.select (new SimuladorQualifier(){}); 


O método select dainterface Instance filtra as possibilidades, agora em vez 
de três, temos apenas um candidato: SimuladoraCalculoFolhaPagamento. 
Mas vamos analisar melhor alguns pontos. 

Há uma sobrecarga do método select, nos permitindo filtrar as possi- 
bilidade através de qualificadores ou pelo tipo. Utilizamos aqui o filtro pelo 
qualificador ESimulador, mas para fazer isso criamos uma classe chamada 


SimuladorQualifier, como podemos ver a seguir. 


public class SimuladorQualifier 
extends AnnotationLiteral<Simulador> implements Simulador { 


private PlanoDeCargos planoDeCargos; 
private boolean planoAprovado; 


private boolean enviarNotificacao; 


public SimuladorQualifier (O) 
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this (PlanoDeCargos.VERSAO 2005, true, true); 


public SimuladorQualifier (PlanoDeCargos planoDeCargos, 


boolean planoAprovado, boolean enviarNotificacao)f 


//os métodos da anotação simplesmente devolvem as propriedades 


Como é possível ver essa classe por padrão especificará o 





PlanoDeCargos.VERSAO 2005 no processo de seleção, ou seja, é como se 
estivéssemos definindo um ponto de injeção como este: 


CInject OSimulador (planoDeCargos = VERSAO 2013) 
private CalculadoraFolhaPagamento calculadoraFolhaPagamento; 


Porém como estamos usando um qualificador com propriedades, temos esse 
grande trabalho para reproduzir essa anotação programaticamente. Se fosse 
um qualificador simples, sem propriedades, bastaria utilizarmos a classe utilitá- 
ria javax.enterprise.util.AnnotationLiteral. Não precisaríamos dessa 
classe SimuladorQualifier, poderíamos reescrever o exemplo anterior da se- 


guinte maneira. 


OInject @Any 
private Instance<CalculadoraFolhaPagamento> todasCalculadoras; 


if (simulacao){ 


Instance<CalculadoraFolhaPagamento> simuladoras = 
todasCalculadoras.select (new AnnotationLiteral<Simulador>()14)); 


A interface Instance nos oferece uma interface fluente, permitindo invocações 
seguidas do método select, onde podemos ir a cada invocação refinando mais o 
filtro dos candidatos a suprir a dependência. Esse mesmo tipo de lookup nós voltare- 
mos a ver na seção 7.4, porém em vez de injetar dependências, estaremos utilizando 
o lookup para especificar dinamicamente o evento que será disparado. 
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4.9 RESUMO DO FUNCIONAMENTO DA RESOLUÇÃO DE DE- 
PENDÊNCIAS 


Como dito no início do capítulo, essa definição ficou para o final pois para chegar 
aqui passamos por diversos exemplos, e sem eles esse resumo poderia ficar muito 
abstrato. Essa será uma seção que talvez valha a pena voltar para relembrar, seja 
durante a leitura deste livro, ou quando tiver dúvidas nos seus projetos. 

Já vimos como funcionam os qualificadores e os beans alternativos. Agora po- 
demos formalizar como a CDI resolve as dependências de uma forma resumida. 


Avaliando o tipo 


O primeiro elemento a ser considerado é o tipo do objeto. O tipo que está no 
ponto de injeção, ou seja, aquele que está pedindo a dependência, é o que chama- 
mos de tipo requerido. Serão considerados beans candidatos aqueles que têm tipos 
compatíveis com o tipo requerido. Se esta for uma interface serão aceitos beans de 
classes que a implementa e subclasses dessas. Se o tipo requerido for uma classe, 
serão aceitos beans do mesmo tipo ou de subtipos do requerido. É só imaginar que 
o teste será feito usando instanceof, se a resposta for verdadeira, o bean será 
elegível. 

Quando se tratar de um tipo primitivo, será considerado o seu tipo wrapper, ou 
seja, o tipo de um int será java. lang. Integer e vice-versa. 

Se o tipo requerido for um tipo genérico, como Dao<xX>, serão aceitos somente 
beans sem tipagem e tipo base exatamente igual ( Dao), ou com tipo parametrizado 
compatível. Por exemplo, Dao<Yy>, onde Y for compatível com (não é o mesmo 
que subtipo de) x. Nos exemplos a frente veremos com mais detalhes. Caso o tipo 
requerido seja genérico e não esteja tipado, como Dao, o bean injetado deverá estar 
sem tipagem ou tipado com Object. 


Por exemplo, se tivermos a dependência a seguir: 


OInject Dao<Pessoa> dao; 


Nesse caso serão aceitos beans dos tipos Dao, sem tipagem alguma, ou 
Dao<Pessoa>. 


Agora vamos considerar que temos também as seguintes classes: 
public class PessoaFisica extends Pessoa { ... + 


public class PessoaDao extends Dao<Pessoa> { ... + 
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Com esse cenário, só seria possível injetar Dao<PessoaFisica> se 
o ponto de injeção definisse Q@Inject Dao<? extends Pessoa>, pois 
Dao<PessoaFisica> não é um tipo compatível com Dao<Pessoa>. Agora, no 
caso em que o coringa foi usado, temos um ponto de injeção compatível pois não 
limitamos o tipo parametrizado a Pessoa, em vez disso incluímos seus subtipos. 

Voltando ao ponto de injeção GInject Dao<Pessoa> dao, conseguiríamos 
também injetar nele uma instância de PessoaDao, pois é um tipo compatível. 

Já analisando os a arrays, só serão considerados se os candidatos forem do 
mesmo tipo do requerido; não são considerados arrays de subtipos do esperado. Por 
exemplo, vamos olhar o ponto de injeção a seguir: 


CInject Pessoal] pessoas; 


Aqui é possível injetar um array do tipo Pessoa [], mas não é possível injetar 
um array do tipo PessoaFisica[], pois, apesar de PessoaFisica ser um tipo 


compatível com Pessoa, os respectivos arrays não são. 


Avaliando os qualificadores 


Além da tipagem, temos os qualificadores e alternativos como já vimos. Caso o 
ponto de injeção especifique um qualificador, serão considerados apenas os beans 
que tenham todos os qualificadores solicitados. Caso não exista um bean com to- 
dos os qualificadores solicitados, a CDI lançará um exceção, pois a dependência não 
pode ser resolvida. 

Para todos os efeitos da resolução de dependências, quando uma dependência 
requer alguns qualificadores, não adianta ter quase todos desses qualificadores, se 
o bean não possuir ao menos um dos requeridos, ele não será escolhido. Já se ele 
possuir os qualificadores requeridos e ainda mais, não haverá problema, o que não 
pode é faltar um qualificador. 

Ainda sobe qualificadores, precisamos lembrar de seus atributos, como já vi- 
mos. Assim sendo, quando um qualificador é especificado, só serão considerados 
aceitáveis beans com os mesmos qualificadores, e cada qualificador deve ter todos 
os atributos com os mesmos valores do qualificador requerido. A exceção é quanto 
aos atributos anotados com ENonbinding, pois esses não são vinculantes. 


Avaliando os alternativos 


Sempre que tivermos vários beans compatíveis com a dependência requerida, 
ou seja, tipo e qualificadores aceitáveis, a CDI verifica se dentre eles há algum bean 


81 


4.9. Resumo do funcionamento da resolução de dependências Casa do Código 





alternativo. Caso exista, os beans não alternativos são descartados, e somente os 
alternativos, que naturalmente tem prioridade, serão avaliados. 

Dentre os beans alternativos restantes, será escolhido aquele de maior priori- 
dade, como visto na seção 4.4. Caso não haja um bean com prioridade superior, 
sejam alternativos com mesma prioridade ou quando tivermos apenas beans não al- 
ternativos, a CDI lançará uma exceção, pois não terá critérios para escolher entre os 
elegíveis; é o caso da ambiguidade que já vimos nesse capítulo. 
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CAPÍTULO 5 


O ciclo de vida dos objetos 
gerenciados pela CDI 


Assim como toda ferramenta de alto nível, como JSF e JPA, quando trabalhamos com 
CDI temos que lidar com o ciclo de vida dos objetos. A partir do momento em que 
não somos nós que instanciamos os objetos, temos que ter uma forma de interagir 
com esse processo, ou no mínimo entender como ele funciona. 

Desde o capítulo 3 temos visto que para termos um objeto injetável, um bean 
CDI, basta que ele esteja dentro de um pacote CDI. Não precisamos sequer anotar a 
classe com algo da CDI. Isso não quer dizer, porém, que não tenhamos uma forma de 
construir objetos que não estão automaticamente disponíveis no seu contexto. Para 
isso usaremos os métodos produtores. 

Temos também uma forma de liberar alguns recursos quando objetos são des- 
truídos, são como métodos destrutores. E entre a criação e a destruição do objeto 
temos seu tempo de vida, que é definido pelo escopo, mais um elemento que veremos 
nesse capítulo. 
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5.1 MÉTODOS PRODUTORES 


Em algumas situações, precisaremos injetar uma classe que não é um bean CDI, 
como a instância de uma classe de alguma biblioteca pré-existente. Um exemplo 
disso é o uso de uma biblioteca de log, como a SLF 4] (www.slf4j.org). Para tal, vamos 
voltar ao exemplo da nossa primeira servlet, IniciandoComCDI, e trocar nossas 
escritas no console pelo uso do SLF4]. 


import org.slf4j.Logger; 
import org.slf4j.LoggerFactory; 


OwebServlet ("/hello-cdi") 
public class IniciandoComCDI extends HttpServlet { 


private Logger logger = 
LoggerFactory.getLogger (IniciandoComCDI.class); 


public IniciandoComCDI() 1 
//System.out.println("Instanciando a Servlet..."); 
logger. info("Instanciando a Servlet..."); 


O uso da API de log é bem simples, como acabamos de ver, mas não seria mais 
interessante se pudéssemos injetar o Logger? 


OInject private Logger logger; 


Nesses casos é que vamos usar os métodos produtores. Novamente temos sorte, 
pois a implementação do produtor é algo extramente simples. 


import javax.enterprise.inject.Produces; 
public class Produtor { 


OProduces 


public Logger criaLogger 01 
return LoggerFactory.getLogger (IniciandoComCDI.class); 
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Bem simples. Basta criarmos um método anotado com GProduces que retorne 
o tipo que queremos produzir. Dessa maneira, quando o ponto de injeção solicitar a 
dependência, a CDI irá chamar o método produtor para gerar o objeto esperado. 

Quando o contexto CDI sobe, as dependências são todas checadas para ver se 
tem beans que as satisfaçam. É nesse momento que a CDI lança exceções caso a 
dependência não possa ser satisfeita ou em caso de ambiguidade, que é quando en- 
contra mais de um candidato compatível. No caso do Logger, como estamos diante 
de um tipo que não é parte de um bean CDI, o normal seria ser lançada uma exce- 
ção dizendo que a dependência não poderia ser satisfeita, mas como temos o método 
produtor, a CDI sabe que conseguirá produzir o bean quando for demandada. 

Como o método produtor ensina uma nova forma de instanciar um bean, caso 
criemos um produtor de uma classe que já está dentro do nosso projeto ou de outro 
pacote CDI, estaremos criando uma ambiguidade, mas no nosso exemplo esse não 
será um problema. 

Porém, se repararmos bem, temos um problema no nosso produtor: ele só pro- 
duz Loggers da classe IniciandoComCDI. Serviu para mostrar o mecanismo 
básico dos produtores, mas obviamente não vai nos servir mais. Para que conse- 
guíssemos resolver esse problema precisaríamos ter uma forma de saber em que 
ponto estará sendo injetado o bean que estamos produzindo. Para isso temos a in- 





terface javax.enterprise.inject.spi.InjectionPoint, que nos dá exa- 
tamente essa informação. 

Entre os métodos dessa interface temos um que devolve onde o objeto está sendo 
injetado. 


public interface InjectionPoint { 
java.lang.reflect.Member getMember (); 


O tipo java. lang.reflect .Member é uma interface, abstração de um cons- 
trutor, de uma propriedade ou de um método de uma classe. Como já vimos na 
seção 3.3, esses são os tipos de ponto de injeção possíveis. 

No nosso exemplo, estamos injetando a dependência em uma propriedade, 
que na API de reflection é do tipo java.lang.reflect.Fiela, uma im- 
plementação de Member. A partir desse tipo acessamos a classe onde a pro- 
priedade está declarada através do método getDeclaringClass (), que nos 
devolve o java.lang.Class que possui nossa propriedade, ou seja, o tipo 


IniciandoComCDI. 
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import javax.enterprise.inject.Produces; 
public class Produtor { 


OProduces 
public Logger criaLogger (InjectionPoint ip) 1 
return Logger.getLogger (ip.getMember() 
. getDeclaringClass() .getName()); 


Agora temos nosso produtor genérico para poder produzir Logger em qualquer 
lugar do nosso sistema. Porém, pode ser que precisemos de mais informações para 
criar o bean, por exemplo o usuário logado, para isso basta injetarmos esse objeto 
no nosso produtor, afinal ele é uma classe normal. 


public class Produtor { 
private Logger logger = LoggerFactory.getLogger (Produtor.class); 


OInject 
private UsuarioLogado usuario; 


OProduces 
public Logger criaLogger(InjectionPoint ip) 1 


Class classe = ip.getMember() .getDeclaringClass(); 


logger.info("Criando log para a classe " + classe + 


"e para o usuário " + usuario); 


return Logger.getLogger (classe.getName()); 


Nesse caso usamos a dependência extra apenas para gerar um log, mas vimos 
como injetá-la. Entretanto, temos uma forma ainda mais simples de fazer isso. Ape- 
sar de podermos ter métodos produtores em qualquer classe, não é incomum termos 
uma classe no nosso sistema com a responsabilidade de produzir diversas dependên- 
cias como o Logger que acabamos de ver. Se nessa classe tivermos vários métodos 
produtores, e alguns deles precisarem de uma ou dias informações extras para gerar 
o bean, pode ser que a classe no final tenha várias dependências. E isso não é o maior 
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problema, o que ocorre é que não fica claro qual dependência está sendo usada para 
produzir qual bean. 

Para resolver esse problema, podemos injetar as dependências no próprio mé- 
todo produtor. Se olharmos de novo, veremos que o próprio InjectionPoint 
foi passado para nosso método como uma dependência. Basta seguirmos a mesma 
lógica para as demais dependências. 


public class Produtor { 


OProduces 
public Logger criaLogger(InjectionPoint ip, UsuarioLogado usuario) { 


Agora, sabemos exatamente quais dependências são necessárias para produzir 
nosso bean. Além disso, a classe fica mais limpa, e o código mais elegante. E simpli- 
cidade e elegância nunca fez mal a código algum. 

Como o produtor é uma forma de colocar uma classe comum (por exemplo de 
biblioteca não CDI) dentro do contexto CDI, podemos especificar no produtor as 
mesmas coisas que podemos anotar na própria classe, como qualificadores e escopos. 
O primeiro já é nosso conhecido, mas o segundo será visto ainda nesse capítulo. 


public class Produtor { 


OProduces OQualificadorX OQualificadorY(VALOR Z) 
public Logger criaLogger(InjectionPoint ip, UsuarioLogado usuario) { 


Propriedade produtora 


Já vimos que os métodos produtores podem estar presentes em qualquer bean, 
mas além de um método, podemos ter uma propriedade anotada com EProduces. 
As regras são basicamente as mesmas dos métodos, a diferença é que caso a propri- 
edade produtora esteja definida dentro de um EJB do tipo Session Bean, esta deverá 
obrigatoriamente ser estática. 

Um exemplo do uso dessa funcionalidade é colocarmos no contexto CDI objetos 
do Java EE. 
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public class ProdutorJava EE { 


OPersistenceContext (unitName="organizacionalDatabase") 
OProduces QOrganizacionalDatabase EntityManager organizacionalEM; 





Nesse exemplo, nós usamos a forma Java EE de injetar o EntityManager do 
banco de dados que chamamos de “organizacional”. Ao mesmo tempo produzimos 
esse mesmo objeto com o qualificador GOrganizacionalDatabase. Com isso, 
as demais classes do sistema podem simplesmente injetar dessa forma: 


OInject OOrganizacionalDatabase 
EntityManager organizacionalEntityManager; 


A vantagem dessa tradução — da forma Java EE para a CDI — é que podemos 
usar apenas a forma CDI de injetar dependências, e com isso rodar nossa aplicação 
também em ambientes não Java EE, como o Tomcat. Nesse último ambiente pode- 


ríamos ter um método produtor como o que segue. 


public class ProdutorJavaSE { 
OProduces QOrganizacionalDatabase 
public EntityManager criaEntityManager Ot 
EntityManagerFactory emf = Persistence 
.createEntityManagerFactory ("organizacionalDatabase"); 


return emf.createEntityManager(); 














} 
} 

Agora, com base no que já aprendemos sobre alternatives, poderíamos 
marcar ambos produtores: ProdutorJava EE e ProdutorJavaSE como 


@Alternatives e habilitar no beans.xml apenas o correspondente ao ambiente 
que estivermos instalando nossa aplicação. 


Restringindo o tipo do bean produzido 


Tanto nos métodos quanto nas propriedades produtoras, podemos utilizar a 
mesma anotação @Typed vista na seção 4.7. Dessa maneira o bean produzido não 
será candidato a suprir dependências de todos os tipos possíveis, mas somente dos 
especificados na anotação e java.lang.Object. 
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OProduces OTyped(CalculadoraDeSalarios.class) 
public CalculadoraDeSalariosPlano2013 criaCalculadora()( 
return new CalculadoraAssincronaDeSalariosPlano2013(); 


5.2 Escorpos DA CDI 


Como estamos falando do ciclo de vida, chegou a hora de falarmos dos escopos, meio 
pelo qual definimos o tempo de vida de um bean. Até agora, nossos exemplos têm 
sido baseado em servlets, que serviram até aqui por serem extremamente simples, 
mas para falarmos de escopos, precisaremos de algo mais flexível, pois as servlets 
são objetos criados uma única vez e vivem enquanto a aplicação estiver rodando. 
Como acompanham o ciclo de vida da aplicação, é como se sempre fossem do escopo 
application. Digo como se fossem pois não especificamos escopos em servlets. 

Pra explorar todos os escopos possíveis, pararemos de usar as servlets e usare- 
mos JSF. Não é objetivo deste livro ensinar JSF, mas o usaremos para exemplificar os 
escopos. Você pode fazer uso de CDI com outros frameworks, mas a escolha do JSF 
é por ser parte do Java EE, assim como o CDI. Para saber mais sobre JSF, e também 
sobre JPA, recomendo o livro “Aplicações Java para a web com JSF e JPA” da editora 
Casa do Código [?]. 

Antes de entrar em um escopo específico, vamos fazer uma tradução bá- 
sica de uma de nossas servlets para um bean JSF. Iniciaremos pela servlet 
IniciandoComCDI, e agora que já passamos pelo hello world, poderemos dar um 
significado melhor para essa classe. 


O código atual dela é o seguinte: 


OwebServlet ("/hello-cdi") 
public class IniciandoComCDI extends HttpServlet { 


OInject 
private CalculadoraDeImpostos calculadoralmpostos; 


public IniciandoComCDI() { 
System.out.printin("Instanciando a Servlet...'"); 


OPostConstruct 
public void ok(){ 
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System.out.println("Servlet pronta."); 


protected void doGet (HttpServletRequest req, 


HttpServletResponse res) 
throws ServletException, IOException { 


double salarioBase = 
Double .parseDouble(reg.getParameter("salario")); 


Funcionario funcionario = new FuncionarioBuilder() 
.comSalarioBaseDe (salarioBase) 
«build O; 


System.out.printiln("Efetuando o cálculo."); 


//a calculadora de IR usa outra classe para calcular o salário 
double imposto = calculadoraimpostos 
.calculaImpostoDeRenda(funcionario); 


res.getOutputStream() .print( 
String.format ("Salario base: R$ %.2f\n" + 
"Imposto devido: R$ 4.2f", salarioBase, imposto)); 
System.out.printin("Fim.'"); 


O primeiro passo para mudarmos nossa servlet, é transformá-la em uma classe 


Java simples, também conhecida como POJO (Plain Old Java Object), ou seja, a 


boa e velha classe Java, que não precisa implementar interfaces ou estender clas- 


ses de algum framework. Agora, como nossa classe não é mais uma servlet, o mé- 


todo doGet vai virar um método simples, que renomearemos para algo significativo, 


como calculaImposto. E aproveitando a mudança de nome, vamos dar também 


um nome significativo para a classe: 


public class CalculadoraImpostosBean { 


OInject 
private CalculadoraDeImpostos calculadoralImpostos; 
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public CalculadoraImpostosBean() { 
System.out.printin("Instanciando a CalculadoraImpostosBean...'"); 


OPostConstruct 
public void ok(){ 
System.out.println("CalculadoraImpostosBean pronta."); 


public void calculaImposto (HttpServletRequest req, 
HttpServletResponse res) 
throws ServletException, IOException 1 


double salarioBase = 
Double. parseDouble(req.getParameter ("salario")); 


Funcionario funcionario = new FuncionarioBuilder() 
.comSalarioBaseDe(salarioBase) 
“build O: 


System. out .println("Efetuando o cálculo."); 


//a calculadora de IR usa outra classe para calcular o salário 
double imposto = calculadoraImpostos 
.calculaImpostoDeRenda (funcionario); 


res.getOutputStream() .print( 
String.format("Salario base: R$ %.2f\n" + 
"Imposto devido: R$ 4.2f", salarioBase, imposto)); 
System.out.printin("Fim.'"); 


Estamos mudando a classe aos poucos: por enquanto mudamos basicamente 
o nome da classe, inclusive nas mensagens que saiam no console. Agora vamos 
arrumar a assinatura do método calculaImposto, que ainda está com cara de 
servlet. Colocaremos uma propriedade na nossa CalculadoraImpostosBean 
que armazenará a informações que antes vinha do objeto req, do tipo 
HttpServletRequest. 
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public class CalculadoraImpostosBean { 
//o resto permanece igual 


private double salarioBase; //getters e setters 
private double imposto; //getters e setters 


public void calculaImposto() { 


Funcionario funcionario = new FuncionarioBuilder() 
.comSalarioBaseDe(salarioBase) 
«build (O); 


System.out.println("Efetuando o cálculo."); 
imposto = calculadoraImpostos.calculaImpostoDeRenda (funcionario); 


System.out.printin("Fim.'"); 


No nosso novo código o imposto é calculado e armazenado em uma proprie- 
dade do bean, pois no mundo real nossas classes de negócio apenas efetuam a lógica 
da aplicação, elas não são responsáveis pela apresentação dos resultados ao usuá- 
rio. Para isso criaremos uma página JSF simples, que apenas terá um campo para a 
entrada do salário e no final apresentará o valor do imposto. 


<html xmlns="http://www.w3.0rg/1999/xhtml" 
xmlns:h="http://xmins.jcp.org/jsf/html"> 
<h: form> 
<h:panelGrid columns="2"> 
Salário base: 
<h: inputText value="(calculadoraImpostosBean.salarioBase)J"/> 


Imposto Calculado: 
<h:outputText value="k(calculadoraImpostosBean. imposto)"/> 


<h: commandButton value="Calcular Imposto" 


action="t(calculadoraImpostosBean.calculaImposto()J"/> 
</h:panelGrid> 
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</h:form> 
</html> 


Mas antes de executar essa página, precisamos dar um nome ao nosso bean, 
como vimos na seção 4.5. Para isso temos que fazer uma última alteração no nosso 
bean: 


ONamed 
public class CalculadoraImpostosBean { ... 5 


Na página que criamos temos o componente h:panelGrid que serve apenas 
para fazer a formatação da página. Com ele, especificamos a quantidade de colunas 
que desejamos ter. Como especificamos duas colunas, significa que a cada dois com- 
ponentes — no exemplo a label e o componente JSF — será criada uma nova linha. 
Assim não nos preocupamos com o alinhamento, e a saída já ficará igual à seguinte: 


800 
R. reen , q 
(< Ea | |% | | @ localhost:8080/livro-cdi/faces/calcular-impostos.xhtmi 


| Es http://localhos...-impostos.xhtml [TR 


Salário base: 0.0 
Imposto Calculado: 0.0 


Calcular imposto | 








Figura 5.1: Formulário da calculadora de impostos feita com JSF 


Os demais componestes são de input e output simples, além do botão que executa 
a ação, chamando o método ligado à propriedade action. 

Se executarmos nossa aplicação como está, veremos que o valor apresentado no 
imposto estará zerado, mas isso porque não especificamos nenhum escopo. Em vá- 
rios dos nossos beans realmente não especificaremos nenhum escopo e isso não será 
um problema, porém sem passar pelos outros será mais difícil entender esse escopo 
default. Por isso, voltaremos a falar dele na seção 5.7. 
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5.3 ESCOPO DE REQUISIÇÃO COM @REQUESTSCOPED 


O escopo request é o mais comum em uma aplicação web, pois toda interação entre 
o browser e o servidor é um request. Esse escopo define um ciclo de vida que se 
inicia no momento em que a requisição do usuário chega no servidor, e dura todo 
o processamento e também todo o processo de geração da resposta para o usuário. 
Somente quando a resposta para o usuário é terminada que o request termina. 

Parece simples, mas é preciso ficarmos atentos principalmente a essa última 
parte: a geração da resposta para o usuário. Não adianta acompanharmos a exe- 
cução passo a a passo de toda a lógica da aplicação e achar que está tudo certo, pois 
se algo ocorrer depois do processamento, mas antes da geração da resposta terminar, 
ainda podemos ter problema, pois o ciclo como um todo é que importa. 

Uma forma de tentarmos ilustrar o funcionamento desse escopo é através da 
figura a seguir: 


Cliente Servidor 


leditar.jsf 


Request D A 


<— | $ 











Figura 5.2: Ilustração do escopo request 


Na figura exemplificamos a chamada da URL /editar. jsf. Como já foi dito, 
o bean é criado no momento em que a requisição chega no servidor, e termina no 
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momento em que sai dele. Novamente precisamos nos atentar, pois a resposta é 
gerada toda no servidor. Às vezes, em uma olhada rápida, podemos pensar que o 
request terminaria na chegada da resposta ao browser, mas essa volta nada mais é do 
que uma transferência pela rede de um HTML pronto. 

Retornando ao nosso exemplo, basta colocarmos a anotação do escopo request 


que as coisas funcionarão: 


import javax.enterprise.context.RequestScoped; 
import javax.inject.Named; 


ONamed ORequestScoped 
public class CalculadoraImpostosBean { ... } 


A cada clique no botão "Calcular Imposto" estaremos disparando 
uma nova requisição. A cada requisição, será criada uma nova instância de 
CalculadoraImpostosBean, que receberá suas dependências e calculará o im- 
posto. Depois o JSF, assim como faria uma página JSP, acessa o bean para buscar 
os valores que precisa para montar a tela de resposta. Após terminar a geração da 
resposta, o request termina, e como todos esses beans estão nesse escopo, nesse mo- 
mento eles são retirados da memória. 

Como este é o primeiro escopo que estamos vendo, vamos ver mais uma ilustra- 


ção que nos auxilia a compreender esse ciclo: 
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Funcionamento do escopo request 


ColeuladoraTmpostosBean 


fealeularimpostos,jsÊ 


Calculadora DeSalarios 











CaleuladorarmpostosBean0O) 


Calculadora Dermpostos(Caleuladora DeSalarios) 





Calculadora DeSalarios() 


@PostConstruct 


@PostConstruct 





@PostConstruct < 
caleulaTmpostol) 








caleulaSalariFuncionario) 














resultado 


CoaleladorarmpostosBean Calculadora DeImpostos Calevladora DeSalarios 


Figura 5.3: Ciclo da requisição do cálculo de imposto 








Podemos dividir essa imagem em duas partes, a primeira mostra o pro- 
cesso de criação do bean, parecido com o que fizemos na seção 3.1, mas na- 
quele momento usamos a análise de console, agora estamos vendo graficamente. 
No nosso caso temos três beans envolvidos CalculadoraImpostosBean -> 
CalculadoraDeImpostos -> CalculadoraDeSalarios, e nossa figura ilus- 
tra essa dependência. 

Na segunda metade, temos a chamada do método 
calculadoraImpostosBean.calculaImposto() pelo botão da nossa 
tela. E depois da resposta entregue ao navegador, os beans são removidos da 
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memória pois o escopo — request — termina. 

Se desconsiderarmos a chamada do método e analisarmos apenas o processo 
de criação dos beans, e ao final a seu descarte, estaremos analisando exatamente 
o mesmo funcionamento independentemente do escopo. Conforme formos anali- 
sando os demais escopos isso ficará mais claro. 


5.4 ESCOPO DE SESSÃO COM O QSESSIONSCOPED 


O processo de criação e descarte de um bean não muda se o escopo é request ou 
session, o que muda é quando o processo ocorre. Enquanto o request compreende 
cada invocação ao servidor feita pelo cliente, a sessão engloba todas as requisições 
de um mesmo cliente. Para facilitar, é só imaginar o processo de autenticação em 
uma aplicação web. Enquanto tivermos com o browser aberto, estaremos logados na 
aplicação, isso porque as informações de autenticação costumam ficar no escopo de 
sessão. 

Cada vez que acessamos uma aplicação pela primeira vez, com um determinado 
navegador, é criada uma nova sessão. Mas isso não cria automaticamente os beans 
de escopo sessão, estes geralmente são criados quando utilizados pela primeira vez, e 
duram enquanto a sessão existir. Enquanto conseguimos perceber pelo console que, 
no escopo request, os objetos são recriados a cada solicitação; com o escopo sessão, 
só perceberemos essa criação uma vez para cada browser utilizado. 

Geralmente a sessão é mantida através de um cookie ou então algum parâmetro 
na url que é gerado pelo servidor, assim conseguimos abrir mais de uma sessão se 
usarmos browsers diferentes ou a chamada sessão anônima suportada pelos navega- 
dores mais modernos. 

Para testar a criação sessões, é possível fechar o browser e abrir novamente pra 
criar uma nova sessão, mas isso não significa que a antiga será fechada. Geralmente 
o que ocorre quando um usuário fecha o browser sem usar alguma opção “sair” da 
aplicação, é que a sessão ficará inativa no servidor, ocupando recursos desnecessari- 
amente, até que o timeout seja alcançado. Isso geralmente ocorre após trinta minutos 
de inatividade. 


A seguir uma imagem para ilustrar esse funcionamento. 
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Cliente Servidor 





listar.jsf 





o) ~ 30 min. depois Éú 


Figura 5.4: Ilustração do escopo de sessão 
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No desenvolvimento de aplicações reais, muitas vezes surgem funcionalidades 
cujos estados são mais difíceis de gerenciar do que uma simples requisição, e o pri- 
meiro impulso pode ser mudar o escopo do bean para sessão. Esse procedimento 
resolve o problema em tempo de desenvolvimento, mas cria um novo problema em 
tempo de execução. 

Simplesmente passar um bean para escopo de sessão faz com que a aplicação 
passe a consumir recursos de forma exagerada. Recursos que deveriam ser manti- 
dos por poucas requisições acabam ficando na memória enquanto o usuário estiver 
logado, um desperdício. A melhor prática na programação como um todo, é sem- 
pre usar o menor escopo que resolva o problema, e quando falamos de escopo isso é 
ainda mais importante. Antes de mudar o escopo de um bean de request para session 
por este primeiro parecer pequeno demais para a funcionalidade, olhe o escopo de 
conversação na seção 5.6. 

Como o exemplo das informações de autenticação do usuário, o escopo de ses- 
são serve para armazenar informações que devem estar em memória durante toda 
a navegação do usuário na aplicação. Outros exemplos podem ser as permissões 
do usuário, informações de perfil de acesso, nome, hora do login, entre outras que 
possam ser interessantes dependendo da aplicação. 


5.5 (DAPPLICATIONSCOPED: O MAIOR ESCOPO POSSÍVEL 


O escopo de aplicação não foge do funcionamento padrão, a dinâmica é a mesma, a 
diferença está em sua amplitude. Enquanto o escopo request dura uma única requi- 
sição de um determinado usuário, e sessão engloba toda a utilização do sistema por 
um usuário, a aplicação envolve todos usuário da aplicação. Assim, se colocarmos 
algo nesse escopo, estará disponível para qualquer usuário que acessar a aplicação. 

Um exemplo seria a funcionalidade de listar todos os usuários que estão online, 
e quem sabe até um chat entre eles. É um escopo que cruza todas as sessões, então 
se temos que tomar cuidado ao por algo no escopo sessão, temos que redobrar isso 
no escopo aplicação. 

Ainda como exemplo de aplicações para esse escopo, poderíamos pensar em lis- 
tagens fixas, como estados e municípios. Esse pode ser um uso legítimo, pois re- 
almente é algo comum a qualquer usuário, mas existem outras opções. Nesse caso, 
podemos utilizar um cache de segundo nível na camada de persistência, algo da JPA, 
e não da CDI. Uma boa maneira de desenvolver aplicações é procurar sempre usar a 
solução correta para cada problema. Muitas vezes colocar algo no escopo aplicação 
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pode resolver, mas se puder utilizar uma solução de cache, terá nas mãos uma opção 
mais robusta. 


Para ilustrar o funcionamento desse escopo temos a seguinte imagem: 


Cliente Servidor 


lhome.jsf 


y 
| 


Nistar.jsf 


=$ 





® 





Figura 5.5: Ilustração do escopo de aplicação 


Como vimos, o escopo só termina quando baixamos a aplicação, então colo- 
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cando algo aqui, estaremos adicionando algo na memória que ficará lá por muito 
tempo. 


5.6 (DCONVERSATIONSCOPED: VOCÊ CRIANDO SEU PRÓ- 
PRIO ESCOPO 


O escopo de conversação, é um pouco diferente dos anteriores porque ele possui 
dois comportamentos distintos. Não basta anotar o bean com esse escopo, temos 
que escolher quando passar a conversação de um estado para o outro. 

Uma conversação é um escopo inteligente, que por padrão se comporta como 
o escopo request, perdendo seu estado a cada requisição. O interessante é que po- 
demos escolher um dado momento para que o escopo se torne persistente, como se 
fosse o escopo de sessão. Porém, enquanto este permanece na memória por muito 
tempo, podemos dizer à conversação que ela volte a se comportar como o escopo 
request, então os dados nela armazenados são descartados ao final da próxima re- 
quisição, e ela volta a se comportar como o request. 

O estado padrão, parecido com request é chamado de transient, que é quando 
os estados não são mantidos. Já invocando o método Conversation.begin() 
nossa conversação passa para o estado long-running, e este mantém os dados até que 
o método Conversation.end() seja chamado, quando volta a ser transient e os 
dados deixam de ser armazenados. A imagem a seguir ilustra esse funcionamento. 
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Cliente Servidor 
leditar.jsf 

| Request > A 
leditar.jsf 


A conversation.begin() 


leditar.jsf 
Request 


— Response 


Nistar.jsf 


Request 








transient 


long-running 





transient 


Figura 5.6: Ilustração do escopo de conversação 


102 


Casa do Código Capítulo 5. O ciclo de vida dos objetos gerenciados pela CDI 





Vamos analisar como implementamos isso no nosso código. Como já foi dito, 
no caso da conversação não basta anotar o bean, temos que definir quando ela pas- 
sar de um estado para outro. Criaremos no nosso sistema a funcionalidade de cal- 
cular uma folha de pagamento baseado em uma lista de funcionários que vamos 
adicionando um a um. Nosso exemplo será mais simples do que seria um exem- 
plo real, e para simplificar, em vez de usarmos banco de dados, usaremos a classe 


FuncionarioBuilder 


import javax.enterprise.context.Conversation; 
import javax.enterprise.context.ConversationScoped; 


CConversationScoped ONamed 
public classe CalculadoraFolhaBean implements Serializable { 


OInject 
private Conversation conversation; 


OInject 
private CalculadoraFolhaPagamento calculadoraFolha; 


public void iniciaConversacao()1 
if(conversation.isTransient 0) 
conversation.begin(); 


public void terminaConversacao()( 
if(!conversation.isTransient ())f 
conversation.end(); 


O primeiro passo é criarmos um bean nomeado para que seja aces- 
sível da nossa página JSF Como acabamos de ver, não basta anotar 
o bean com o escopo, precisamos injetar uma instância da interface 





javax.enterprise.context.Conversation e utilizá-la para gerenciar 
os estados da conversação. Além de iniciar e finalizar a conversação (alternar entre 
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transient e long-running), temos o método setTimeout (long milliseconds), 
que usamos para mudar o timeout dessa conversação específica. Injetamos também 
uma instância de CalculadoraFolhaPagamento que é quem sabe fazer o 
cálculo que precisamos. 

É importante também que nosso bean, e todos os beans injetados, como 
CalculadoraFolhaPagamento, implementem a interface Serializable. Sem 
isso será lançada uma exceção durante a inicialização da aplicação. 

Criaremos uma tela simples, onde podemos informar o salário de um funcioná- 
rio e adicioná-lo na lista através de um botão. Teremos um outro botão para efetuar o 
cálculo e outros dois para iniciar e terminar a conversação. Além desses componen- 
tes, escreveremos a quantidade de funcionário que já estão na lista, e, assim, vamos 
percebendo a alteração de estado do nosso bean antes de cálculo. O código da tela 
pode ser visto a seguir. 


<html xmlns="http://www.w3.0rg/1999/xhtml" 
xmlns:h="http://xmins.jcp.org/jsf/html"> 
<h:form> 
<h:panelGrid columns="2"> 

Salário base: <h: inputText 
value="H(calculadoraFolhaBean.salarioFuncionario)"/> 

Funcionário adicionados: <h:outputText 
value="t(calculadoraFolhaBean.funcionarios.size()J"/> 

Valor da Folha: <h:outputText 
value="t(calculadoraFolhaBean.folha != null ? 


calculadoraFolhaBean.folha.valor : 'Não calculado'}"/> 


<h: commandButton value="Inicia Conversação" 
action="f(calculadoraFolhaBean. iniciaConversacao()J''/> 

<h: commandButton value="Termina Conversação" 
action="f(calculadoraFolhaBean.terminaConversacao ()J''/> 

<h: commandButton value="Adicionar Funcionário" 
action="f(calculadoraFolhaBean.adicionaFuncionario()+"/> 

<h: commandButton value="Calcular Folha!" 
action="f(calculadoraFolhaBean.calcularFolha()+"/> 

</h: panelGrid> 
</h: form> 
</html> 


Nossa tela, quando executando, se parecerá com essa: 
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Salário base: 00 

Funcionário adicionados: O 

Valor da Folha: Não calculado 

| Inicia Conversação | | Termina Conversação | 
| Adicionar Funcionário | | Calcular Folha! | 


Figura 5.7: Tela de cálculo de folha 


Porém ainda precisamos do restante da implementação da classe 


CalculadoraFolhaBean 


CNamed CConversationScoped 
public class CalculadoraFolhaBean implements Serializable( 


private FuncionarioBuilder builder; 

private Folha folha; //getter 

private List<Funcionario> funcionarios; //getter 
private double salarioFuncionario; //getter e setter 


OPostConstruct 

public void init(){ 
builder = new FuncionarioBuilder(); 
funcionarios = new ArrayList<>(); 


public void adicionaFuncionario()1 
Funcionario funcionario = builder 
.comSalarioBaseDe(salarioFuncionario).build(); 
getFuncionarios() .add (funcionario); 
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public void calcularFolha 0 
folha = calculadoraFolha.calculaFolha(getFuncionarios()); 


E como até agora não tínhamos visto a implementação da 
CalculadoraFolhaPagamentoReal, veremos agora: 


public class CalculadoraFolhaPagamentoReal implements 
CalculadoraFolhaPagamento, Serializable ( 


OInject 
private CalculadoraDeSalarios calculadoraDeSalarios; 


OOverride 
public Folha calculaFolha(List<Funcionario> funcionarios) { 
double valor = 0.0; 
for (Funcionario funcionario : funcionarios) { 
valor += calculadoraDeSalarios.calculaSalario (funcionario); 


} 


return new Folha(new Date(), valor, funcionarios); 


Nossa calculadora está pronta para ser testada. Experimente digitar o sa- 
lário do funcionário no campo correspondente e acione o botão "Adicionar 
Funcionário". Altere o valor do salário e acione o botão novamente. Você perce- 
berá que sem iniciar a conversação, nunca conseguirá sair de um único funcionário 
adicionado. 

Se observar a imagem 5.6, perceberá que antes de iniciar a conversação, o bean 
morre logo após o término da requisição. Assim, por mais que a tela apresente 
a informação de que a lista já contém um Funcionario, no servidor o bean 
CalculadoraFolhaBean já foi destruído, e quando acionar o botão "Adicionar 
Funcionário" mais uma vez, estaremos na verdade recriando todos os objetos, e 
adicionando neles o primeiro Funcionario novamente. 

A partir do momento em que clicamos no botão "Inicia Conversação", 
transformamos a conversação em long-running conversation, e com isso a 
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CalculadoraFolhaBean não morre mais após o término da requisição. Nos pró- 
ximos acionamentos desse botão perceberemos que a contagem de funcionários vai 
aumentando, e podemos finalmente usar o botão "Calcular Folha!”". 

Experimente também utilizar o botão "Termina Conversação", e perceba 
que na próxima ação nossa aplicação se comportará novamente como se fosse a pri- 
meira execução. Isso porque, ao transformarmos uma conversação long-running em 
transient, fazemos com que o bean CalculadoraFolhaBean volte a ser descar- 
tado ao final de cada requisição. 

Nesse exemplo utilizamos um único bean e uma única tela para facilitar o enten- 
dimento, mas uma conversação pode durar por várias telas e diferentes bean dentro 
da nossa aplicação. Realmente esse é um escopo bastante versátil. 

Além desse escopo ter o modo “liga-desliga” de armazenamento de dados, ainda 
que esqueçamos de finalizar a conversação, ela não será como a sessão que guarda os 
valores por um longo tempo, por exemplo, trinta minutos se nada for feito. No caso 
da conversação, mesmo que esteja no estado long-running, os dados são descartados 
quando a conversação atinge seu timeout. A vantagem é que esse timeout não coin- 
cide com o da sessão, por padrão é de apenas dois minutos, economizando recursos 
mais do que a sessão, ainda que esqueçamos de finalizar a conversação. 

Pode parecer uma boa opção diminuir o tempo da sessão para economizar recur- 
sos, mas isso nos leva a efeitos indesejados. Se deixarmos um tempo muito pequeno, 
podemos derrubar a sessão de usuários que estão lendo algum texto na tela do sis- 
tema, e isso pode causar certo desconforto. Mesmo que você tenha outros meios, 
como cookies, para manter a autenticação do usuário, certamente perderá outras in- 
formações que o usuário possar ter preenchido pouco antes iniciar a leitura do texto. 

Novamente devemos buscar a ferramenta certa para cada problema, e na maio- 
ria das situações veremos que a conversação é um escopo mais apropriado para as 
funções da nossa aplicação do que a sessão. 

Quando estivermos vendo um pouco sobre CDI juntamente com EJBs, vere- 
mos que esse escopo traz outras vantagens, como a capacidade de manter aberto o 





contexto de persistência, EntityManager, durante toda a conversação. Com isso 
temos a vantagem do cache de primeiro nível sempre à mão, mantendo os objetos 
persistentes sempre gerenciados. Mesmo EJBs não sendo objeto deste livro, veremos 
um pouco mais sobre isso quando estivermos apreciando a integração da CDI com 
os demais elementos do Java EE. 
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5.7 (DDEPENDENT: O ESCOPO PADRÃO DO CDI 


O escopo dependente foi o primeiro que utilizamos nos nossos exemplos, e con- 
tinuamos a utilizá-lo o tempo todo. Esse é o padrão, aquele atribuído ao bean 
quando não especificamos outro. Para nossa análise, vamos utilizar o mesmo exem- 
plo do escopo de conversação, onde temos o bean CalculadoraFolhaBean ea 
CalculadoraFolhaPagamento. Enquanto o primeiro tem o de conversação, o 
segundo, que não especifica nenhum explicitamente, tem escopo dependente. 

Agora que temos um exemplo, o entendimento desse escopo é simples. Vimos 
que a CalculadoraFolhaPagamento tem escopo dependente, mas dependente 
de quem? Do CalculadoraFolhaBean, que foi quem solicitou a injeção do bean 
dependente. Assim, se nosso bean não especificar um escopo, ele seguirá o de quem 
o solicitar. 

Antes de iniciarmos a conversação longa, tanto o CalculadoraFolhaBean 
quanto o CalculadoraFolhaPagamento estavam funcionando com escopo de 
conversação em modo transiente. Após iniciarmos a conversação, ambos passaram 
para long-running conversation. Quando um é criado, o outro também, e o mesmo 
ocorre no caso da destruição do bean. Na imagem a seguir, temos uma ilustração de 
como o escopo dependente se comporta quando estiver dependendo de um escopo 
request. 
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Cliente Servidor 


leditar.jsf 


D> 
— Response 


Dlnject 














@RequestScoped @Dependent 


@RequestScoped @Dependent 


Figura 5.8: Ilustração do escopo dependente junto ao escopo request 


E agora uma imagem que mostra o escopo dependente sendo utilizado por um 
bean com escopo de sessão. A dinâmica é a mesma de quando é utilizado por um 
bean com escopo request. O dependente sempre segue o ciclo de vida do bean prin- 
cipal. 
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Cliente Servidor 


editar.jsf 


rm 





A @inject y 


@SessionScoped @Dependent 














Request > 





listar.jsf 


Request > 

















~ 30 min. depois 
© p @SessionScoped @Dependent 


Figura 5.9: Ilustração do escopo dependente junto ao escopo de sessão 


Onde definir os escopos e quais as restrições? 


Não existe uma regra sobre onde definir um escopo, mas o mais comum é defi- 
nirmos nos beans nomeados, que serão acessados pelas nossas páginas JSF ou JSP, e 
estes usam os beans com escopo dependente, e são buscados via tipo e não por nome. 
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Nada impede no entanto que beans não nomeados tenham escopos definidos. 

Uma restrição que temos quanto a escopos, é que beans só acessam outros 
com escopo igual ou maior que o seu. Por exemplo, não tem como um bean 
GApplicationScoped injetar um bean ERequestScoped, porém o contrário 
é possível. 

Também não há restrição que impeça deixarmos um bean nomeado 
com escopo dependente, mas se olharmos a primeira versão do nosso bean 
CalculadoraImpostosBean definido na seção 5.2 veremos que ela não fun- 
cionava. Isso porque o bean estava sendo acessado diretamente pela página JSF 
mas não tinha um escopo próprio, era dependente. Assim, cada vez que a página 
tentava acessar o bean, ou a cada EL que chamava seu nome, era criado um novo 
bean. Então, é obvio que que não funcionaria, pois o valor informado pelo usuário 
acabaria descartado logo em seguida. 


5.8 MÉTODOS FINALIZADORES 


Quando um objeto é criado pelo próprio container, por exemplo o servidor de aplica- 
ções JBoss ou Glassfish, este tem a responsabilidade de gerenciar também o descarte 
desse objeto. Porém quando nós mesmos o criamos e o inserimos no contexto CDI 
através de um método ou propriedade produtora, nós temos que cuidar para que o 
objeto seja retirado da memória de forma correta. 





Um exemplo é a produção de um EntityManager como vimos na seção 5.1. 





Quando injetamos uma instância usando a anotação GPersistenceContext, 


é porque o servidor de aplicações gerencia esse objeto para nós. Assim 





sendo, não precisamos chamar o método EntityManager.close() 
pois o servidor faz isso. Agora se o criamos manualmente usando 











Persistence.createEntityManagerFactory.criaEntityManager, 
nós é que temos a responsabilidade de fechá-lo. 

Para fazer isso, basta definirmos um método e anotar a propriedade que quere- 
mos fechar com GDisposes: 


import javax.enterprise.inject.Disposes; 
public class ProdutorJavaSE { 


OProduces 00rganizacionalDatabase 
public EntityManager criaEntityManager 01 
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EntityManagerFactory emf = Persistence 
.createEntityManagerFactory("organizacionalDatabase"); 


return emf.createEntityManager(); 


public void fechaEntityManager( 
ODisposes COrganizacionalDatabase EntityManager em){ 


em.close(); 


O processo de vinculação do método disposer ao objeto que será descartado 
segue a mesma política da resolução de dependência para os pontos de injeção. 
Perceba que o método finalizador parece um método inicializador, que é anotado 
com @Inject e em cada parâmetro declara uma dependência. A diferença é que, 
em vez de anotar o método, anotamos a propriedade que queremos destruir com 
@Disposes, e as demais anotações e o tipo declarado servem para especificar os 
objetos que podem ser finalizados através do nosso método. 

Assim como no método inicializador, podemos declarar mais parâmetros no mé- 
todo finalizador, a diferença é que somente um deles será referente ao objeto que será 
destruído, os demais serão pontos de injeção. 


public void fechaEntityManager( 
ODisposes 0OOrganizacionalDatabase EntityManager em, 
Logger logger)t 


logger. info("Fechando EntityManager"); 
em.close(); 


Nesse exemplo o parâmetro Logger logger é um ponto de injeção assim 
como podemos ter no método produtor, e serve para auxiliar no processo de finaliza- 
ção do objeto. Poderia inclusive ter qualificadores como qualquer ponto de injeção. 
No entanto se mais de um parâmetro estiver anotado com @Disposes, ou se a CDI 
encontrar mais de um método finalizador para o mesmo bean, será lançado um erro 
durante as validações feitas quando a aplicação é iniciada. 
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CAPÍTULO 6 


Interceptors e Decorators 


Neste capítulo veremos duas funcionalidades muito interessantes: interceptors e de- 
corators. São mecanismos tecnicamente parecidos, mas semanticamente bem dife- 
rentes. Ambos nos permitem, cada um com sua aplicabilidade, estender nossa apli- 
cação de forma elegante, sem mexer, ou mexendo muito pouco no nosso código. 


6.1 IMPLEMENTANDO REQUISITOS TRANSVERSAIS COM IN- 
TERCEPTORS 


Um interceptor, ou interceptador, é uma espécie de web filter da API de servlets, mas 
em vez de agir nas requisições web, funciona nas invocações de métodos dos compo- 
nentes CDI. Os interceptadores têm esse nome porque eles interceptam a chamada 
de método e podem executar ações específicas antes, depois ou no lugar da requisi- 
ção original. 

Se compararmos o funcionamento do filtro e do interceptador, veremos muitas 
semelhanças. 
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Ipriv/cadastro.jsp 


Servlet C 





Figura 6.1: Funcionamento dos filtros web 


Basicamente os filtros web são objetos que interceptam a chamada para uma 
servlet baseados em um padrão de url, que no exemplo foram /+ e /priv/+. 

Já o interceptor, como veremos na imagem a seguir, tem o mesmo funciona- 
mento mas, em vez de padrão de url, baseia-se em anotações específicas para inter- 
ceptar as chamadas de métodos. Além disso, em vez de servlets, com os intercepta- 
dores trabalhamos no nível de beans CDI e seus métodos. 


beanXpto.metodo() 





Figura 6.2: Funcionamento dos interceptadores 


E qual a vantagem disso? Talvez se você nunca criou um filter, não imagina por 
que usaria um interceptor. Esse tipo de funcionalidade é muito importante para im- 
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plementarmos requisitos transversais do sistema. Por exemplo, requisitos de segu- 
rança. 

Enquanto num filtro web poderíamos especificar que todas as requisições do sis- 
tema só podem ser realizadas se o usuário já tiver feito login, podemos especificar 
que um método específico, ou todos os métodos de uma determinada classe, só pode 
ser executado por uma pessoa com determinado perfil. Ou ainda, que após a execu- 
ção de qualquer método de uma classe deve ser gerado um log, assim como faríamos 
ao gerar um log de qualquer requisição web. 


O funcionamento é simples, mas um exemplo facilita ainda mais: 


@WebFilter("/*") 
public class FiltroAutenticacao implements Filter { 


@Inject 
private Logger logger; 


@Override 
public void doFilter(ServletRequest request, 
ServletResponse response, FilterChain chain) 
throws IOException, ServletException { 


//faz um processamento prévio 

HttpServletRequest req = (HttpServletRequest) request; 
HttpSession session = req.getSession(); 

Object usuario = session.getAttribute("usuarioLogado"); 


String paginaDeLogin = "login.jsf"; 
String paginaAtual = req.getRequestURI(); 


if (usuario == null && !paginaAtual.endsWith(paginaDeLogin))f 
//envia para tela de autenticação 
logger.info("usuário não autenticado"); 
((HttpServletResponse)response) . sendRedirect (paginaDeLogin); 

} 

else { 


//chama a ação original 
chain.doFilter(request, response); 


//faz processamento posterior 
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logger.info("terminando requisição para " + paginaAtual); 


Como acabamos de ver, criamos um filtro web que força o usuário a se au- 
tenticar. Poderíamos fazer qualquer tipo de lógica antes e depois da execução 
do que o usuário pretendia fazer, que é representada pela chamada do método 





$chain.doFilter (request, response). E o mais interessante: como a cha- 
mada desse método é o que dispara a execução alvo do usuário, é possível, baseado 
em algum critério, optarmos simplesmente por não fazer essa chamada, ou fazer 
uma outra coisa em seu lugar. É o que ocorre quando o usuário não se autenticou no 
sistema. No lugar de processarmos a requisição para a página que ele tentava acessar, 
enviamo-lo para a tela de login. Trocamos a ação original do usuário por outra mais 
apropriada no momento. 


De forma bastante semelhante podemos definir um interceptor: 


OInterceptor OPriority(Interceptor.Priority.APPLICATION) 
public class Auditor { 


OInject 
private Logger logger; 


CAroundinvoke 
public Object auditar (InvocationContext context) throws Exception 1 


//faz processamento antes 
logger.info("faz processamento anterior"); 


Method method = context .getMethod(); 
Object target = context.getTarget (); 
Object [] params = context.getParameters(); 


logger. info(String.format ("auditando o método: 'hs! " 


+ "do objeto: 'hs! " 


+ "com os parâmetros: 'hs'", method, target, params)); 
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//chama o método original 
logger.info("chama método original"); 
Object retorno = context .proceed(); 


//faz processamento posterior 
logger. info("faz processamento posterior"); 


return retorno; 


A diferença é que o interceptor está trabalhando dentro do contexto CDI, mas 
assim como no filtro, podemos fazer operações antes, depois, ou mesmo substituir 
a execução original por outra coisa, que pode inclusive não fazer nada. Para isso, 
bastaria colocar a invocação do método context .proceed() dentro de um if 
que checasse nossos critérios. É uma forma mais simples, mas que atende à maioria 
dos casos do que anteriormente fazíamos com programação orientada a aspectos, ou 
AOP. 

Em comum também a todas essas formas de implementar requisitos transversais 
está o forte apelo semântico de não utilizá-las para implementar requisitos funcio- 
nais. Isso quer dizer que não devemos codificar requisitos de negócio ali dentro, 
como algum tipo de cálculo. Para essa aplicação temos os decorators, pense em in- 
terceptadores apenas para validações de acesso, auditoria e outras regras gerais. 

Por mais que usando a interface InvocationContext seja possível, concei- 
tualmente um interceptador não deve saber qual classe está interceptando. Obvia- 
mente, saber quem está sendo interceptado não é o problema, podemos usar essa 
informação para gerar um log, por exemplo, mas não para tomar uma decisão de 
negócio. Se você acha que tem essa necessidade, talvez o melhor seja criar um outro 
interceptador com uma função especifica, em vez de fazer ifs dentro de um só, ou 
então criar um decorator. 

Mas se o interceptador não sabe quem está interceptando, como fazemos a li- 
gação entre ambos? Fazemos através dos interceptor bindings. Isso nada mais é do 
que uma anotação que é colocada no interceptador e nas classes ou métodos que 
desejamos interceptar. 


import javax.interceptor. InterceptorBinding; 
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ORetention(RetentionPolicy.RUNTIME) 

OTarget ((ElementType. TYPE, ElementType.METHOD)) 
GInterceptorBinding 

public Ointerface Auditavel {} 


Assim como um qualificador, que vimos na seção 4.2, podemos ter atributos 
dentro dos interceptor bindings, e a menos que a propriedade seja anotada com 





QGjavax.enterprise.util.Nonbinding, só serão ligados beans e interceptors 
que especificarem os mesmos valores para cada propriedade na anotação que faz a 
relação. 

Criada a anotação vinculadora, anotamos a classe ou método que desejamos au- 
ditar. 


OAuditavel 
public class GestoraDePermissoes { ... } 


public class GestoraDePermissoes { 


OAuditavel 
public void mudaPermissoes (Funcionario f, Permissao[] permissoes) 


Podemos também adicionar a meta-anotação 
Gjava. lang.annotation.Inherited no interceptor binding, dessa forma 
nossa anotação será herdável. No nosso exemplo, significa que classes filhas da 
GestoraDePermissoes também serão auditáveis. 


ORetention(RetentionPolicy.RUNTIME) 

OTarget (fElementType. TYPE, ElementType.METHOD)) 
OInherited 

GInterceptorBinding 

public Ointerface Auditavel {} 


OAuditavel 
public class GestoraDePermissoes { ... +) 


public class GestoraAssincronaDePermissoes 
extends GestoraDePermissoes ( ... } 
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Além disso, como veremos na seção 7.1, podemos colocar um ou mais interceptor 
bindings dentro de estereótipos. Assim, um bean com esse estereótipo passa a ser 
interceptado automaticamente. A restrição nesse caso é que só podemos colocar em 











estereótipos interceptor bindings com ETarget (ElementType. TYPE). 





HERDANDO ANOTAÇÕES 


Apesar de não termos comentado dessa possibilidade, podemos utili- 
zar a anotação Gjava.lang.annotation. Inherited também nos 
qualificadores, mas essa possibilidade é desestimulada pela especificação. 
Enquanto a classe filha de um tipo interceptado provavelmente mereça 
ser interceptado também, os qualificadores preferencialmente devem ser 
usado com moderação. 

No exemplo que vimos, faz sentido a 
GestoraAssincronaDePermissoes ser auditável, afinal, ela 
também é uma GestoraDePermissoes, e é auditada. 

Já quando trabalhamos com qualificadores, temos o intuito de indivi- 
dualizar ao máximo cada bean, e se seus subtipos herdarem seus qualifi- 
cadores teremos mais chances de acontecerem problemas de ambigui- 
dade. Se quisermos que um subtipo tenha os mesmos qualificadores, 
pode ser o caso de usarmos ESpecializes, como vimos na seção 4.6. 











Ainda falta algo para que nosso interceptor funcione como pretendido: adicio- 
nar nele a anotação vinculante. Podemos inclusive colocar mais de uma anotação 
de binding no mesmo interceptor, mas no nosso exemplo usaremos apenas a recém 


criada CAuditavel. 


OInterceptor OAuditavel OPriority(Interceptor.Priority.APPLICATION) 
public class Auditor { 


Agora sim temos nosso interceptador funcionando como esperávamos, pois 
além de especificar qual interceptor binding ele usará, já o ativamos com a anota- 
ção @Priority. Assim como fizemos com os beans alternatives, utilizamos essa 
anotação não só para ativar, mas também para definir a prioridade, ou ordem de 
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execução do nosso interceptor. Isso, porém, só é possível se estivermos utilizando 
CDla.. 

Se estivermos utilizando a versão 1.0, precisaremos registrar nossos intercepta- 
dores via arquivo beans . xm1, e não conseguimos definir a ordem de execução dos 
mesmos; pelo menos não sem utilizar alguma configuração específica de alguma 
implementação ou biblioteca auxiliar. Para ativar nosso interceptador sem utilizar a 


anotação EPriority, precisaremos configurar da seguinte maneira. 


<beans xmlns="http://xmlns.jcp.org/xml/ns/javaee" 
xmins:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee 
http://xmlns.jcp.org/xml/ns/javaee/beans 1 1.xsd"> 
<interceptors> 
<class> 


br.com.casadocodigo.livrocdi.interceptador. Auditor 


</class> 
<class>...</class> <!-- um interceptador em cada tag class --> 
</interceptors> 
</beans> 


Assim como não conseguimos definir a ordem de execução apenas com o ar- 
quivo beans.xml, não temos como definir a ordem de execução dos intercepta- 
dores se estes possuírem a mesma prioridade ( GPriority). Porém, se tivermos 
interceptadores com prioridades diferentes, será executado primeiro aquele que ti- 
ver um número de prioridade menor. Ou seja, interceptador com prioridade 1 (um) 
executa antes do que tiver prioridade 10 (dez). 

Apesar de termos visto um funcionamento parecido com o do filtro web, uti- 
lizando a anotação GAroundInvoke, é possível definirmos mais alguns modos de 
interceptação com CDI. Todos os tipos que veremos a seguir utilizam a mesma forma 
de fazer binding entre o bean interceptado e o interceptador, a diferença fica apenas 
no momento em que o método do interceptador será chamado. 


Interceptador & AroundTimeout 


Este tipo de interceptador é utilizado quando desejamos interceptar a execução 
de métodos invocados pelo serviço de timer do Java EE. São aqueles métodos geral- 
mente anotados com ETimeout ou ESchedule: 


OSchedule (hour = "x", minute = "x*/10") 
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public void importaDadosDoFTP ()1 


Nesse exemplo, consideramos que nosso sistema a cada 10 (dez) minutos 
busca algum tipo de dado no FTP. Porém, esse serviço de timer só funciona se 
nosso bean foi um EJB, e nossos exemplos não são EJBs. Como estamos falando 
de interceptadores, é importante citarmos esse tipo. Para interceptarmos as in- 
vocações dos métodos disparados pelo serviço de timer, utilizamos a anotação 
Gjavax. interceptor.AroundTimeout, como podemos ver a seguir. 


CAroundTimeout 
public Object timer (InvocationContext context) throws Exception ( 


//£az algo antes 
Object target = context.getTarget(); 


Object retorno = context.proceed(); 


//£az algo depois 
return retorno; 


É interessante notar, ainda, que o método importaDadosDoF TP () pode ser in- 
vocado tanto pelo serviço de timer quanto diretamente por um cliente do EJB no qual 
ele está definido. Porém como temos duas formas de chamar o mesmo método, po- 
demos ter tanto um interceptador GAroundTimeout quanto um GAroundInvoke 
aptos a interceptar esse método. Como sabemos qual será chamado? A CDI cuida 
disso corretamente. Se o método for chamado diretamente pelo cliente do EJB, o 
interceptador utilizado será 0 &AroundInvoke, mas se for chamado via timer, será 


utilizado o AroundTimeout. 


6.2 INTERCEPTADORES DE CICLO DE VIDA 


Além dos tipos de interceptadores que vimos, existem os interceptadores de ci- 
clo de vida. Dois deles utilizam anotações que já usamos há muito tempo: 


121 


6.2. Interceptadores de ciclo de vida Casa do Código 





GPostConstruct e €PreDestroy, e servem para interceptar o mesmo momento 
que ativa os métodos anotados por elas. Já o terceiro, nos permite interceptar o cons- 
trutor dos beans, e será por ele que iniciaremos. 


Interceptador é AroundConstruct 


Ao utilizar a anotação Rjavax. interceptor.AroundConstruct definimos 
um interceptador que, em vez de interceptar a chamada de um método qualquer do 
nosso bean, intercepta a chamada do seu construtor. 


CAroundConstruct 
public void interceptaConstrutor (InvocationContext context) 
throws Exception { 


context .proceed(); //chama o construtor interceptado 
Object objetoRecemCriado = context.getTarget(); 


Como nesse caso estamos interceptando o construtor do bean, a chamada de 
context .proceed () faz com que o objeto cujo construtor foi interrompido seja 
criado. Se não chamarmos esse método, o objeto não será criado. Apenas após a 
chamada do método proceed() conseguimos recuperar o objeto recém criado 
através do método get Target () do InvocationContext. Esse objeto,porém, 
não está com suas dependências povoadas, então podemos ter problemas como 





NullPointerException se tentarmos executar algum de seus métodos. 





Obviamente, se nosso objeto alvo definir que suas dependências deverão ser to- 
das satisfeitas via seu construtor, teremos o objeto recém criado já com essas de- 
pendências, mas como alguns objetos podem receber dependências de outra forma, 
fazer uso do objeto novo é arriscado. Até porque, voltando à premissa de que o inter- 
ceptador não deve conhecer qual objeto está sendo interceptado, é impreciso fazer 
muitas suposições sobre como este objeto recebe suas dependências. 

Só teremos certeza que o objeto está totalmente montado quando o método ano- 
tado com EPostConstruct for invocado. Porém até agora só utilizamos essa ano- 
tação para definir métodos dentro do próprio bean que foi criado. Mas temos tam- 
bém a opção de interagir com esse momento via interceptadores. 
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Interceptadores & PostConstruct e WPreDestroy 


Desde o início dos nossos exemplos temos utilizado GPostConstruct para 
que nossos beans saibam quando estão prontos, com todas as dependências satisfei- 
tas, e assim possam fazer algo. De forma parecida, podemos utilizar EPreDestroy 
para executar alguma operação antes do nosso bean ser removido da memória. 


Até aqui, nossa utilização tem se parecido com a seguinte. 


ONamed ORequestScoped CAuditavel 
public class CalculadoraImpostosBean { 


OInject private CalculadoraDeImpostos calculadoraimpostos; 


OPostConstruct 
public void init(){ 
System.out.println("CalculadoraImpostosBean pronta."); 


OPreDestroy 
public void destroy 01 
System.out.println("CalculadoraImpostosBean indo embora."); 


Essa é a forma de utilizar essas anotações dentro do próprio bean, mas podemos 
utilizá-las também em um interceptor. Como em todos os demais tipos, a vinculação 
entre o interceptor e o bean é feita via interceptor bindings. No nosso exemplo, esse 
binding é feito pela anotação GAuditavel, e nosso interceptador éo Auditor. 


CInterceptor OAuditavel OPriority(Interceptor.Priority.APPLICATION) 
public class Auditor { 


OPostConstruct 
public void postConstruct (InvocationContext context) 
throws Exceptiont 
Object target = context.getTarget (); 


//chama método anotado com OPostConstruct, se houver 
context .proceed(); 
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OPreDestroy 
public void preDestroy (InvocationContext context) throws Exception 
Object target = context.getTarget(); 


//chama método anotado com OPreDestroy, se houver 
context .proceed(); 


Basicamente, a diferença é que ao remover os métodos de callback de dentro 
do próprio bean, conseguimos dar um comportamento mais uniforme dentro do 
nosso sistema. Não precisamos repetir várias vezes o mesmo código que cria um 
log mostrando o ciclo de vida de cada um dos beans do sistema. Basta fazer isso no 
interceptor e vinculá-lo ao bean através da anotação de vinculação — no exemplo, a 
GAuditavel. 

Note também que por estarmos interceptando o método original, sempre temos 
a opção de chamá-lo ou não via método proceed (). Nesse exemplo acima, o bean 
pode até não ter um método de callback dentro dele, mesmo assim o interceptador 
consegue capturar o momento apropriado. Agora, se o bean tiver esses métodos 
dentro dele, os mesmos serão executados no momento em que chamamos o método 


proceed(). 


6.3 ESTENDENDO UM BEAN EXISTENTE COM DECORATORS 


Decorators em CDI nada mais são do que uma forma de implementarmos o padrão 
de projeto de mesmo nome. Logo, a definição de um se aplica ao outro. 

Um decorator, ou decorador, é um objeto que estende as funcionalidades de um 
objeto já existente, para isso ele precisa ter a mesma tipagem do objeto decorado. A 
grande sacada desse padrão é que em vez de estender o objeto original e sobrescrever 
os métodos que desejamos alterar ou criar novos métodos, fazemos isso de forma 
dinâmica, em tempo de execução. Vamos ver isso de forma gráfica para facilitar o 
entendimento. 
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Cliente Implementação comum 
Dlnject public class CalculadoraDeSalariosPlano2005 
CalculadoraDeSalarios calculadora; implements CalculadoraDeSalarios ( 
public void calcular() ( public double calculaSalario(...X 
calculadora.calculaSalario(...); oo 
} } 




















Figura 6.3: Implementação simples de uma interface 


Iniciamos vendo uma classe cliente utilizando uma simples implementação de 
uma interface, que no caso foia CalculadoraDeSalarios. Até aqui nada de 
novo, mas vai nos ajudar a perceber a evolução do exemplo. A seguir veremos uma 
forma de estender a implementação que acabamos de ver. 


E Extensão do original 
Cliente 





public class CalculadoraDeSalariosPlano2013 
@inject extends CalculadoraDeSalariosPlano2005 { 
CalculadoraDeSalarios calculadora; 





@Override 
public double calculaSalario(...){ 
double s = super.calculaSalario(...); 


public void calcular() ( 


calculadora.calculaSalario(...); 




















Figura 6.4: Estendendo a implementação original 


Quando estendemos uma implementação existente, como no 
exemplo que acabamos de ver, podemos sobrescrever os métodos 
existentes e chamar a implementação original através do super. 
Como a classe CalculadoraDeSalariosPlano2013 estende a 


CalculadoraDeSalariosPlano2005, e esta, por sua vez, implementa a 
interface CalculadoraDeSalarios, logo, a implementação do plano de 2013 
também implementa essa interface, e por isso pode ser usada pela nossa classe 
cliente. 

Essa é uma forma legítima de estender um comportamento, tanto é que a própria 
linguagem nos dá meios de fazê-lo, mas novamente temos que tomar cuidado com 
a semântica. Será que a implementação do plano de 2013 é a implementação do 
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plano de 2005, ou simplesmente a usa? Quando usamos extensão ou implemen- 
tação, lemos que uma classe é do tipo estendido ou implementado. Ou seja, a 
CalculadoraDeSalariosPlano2005 é uma  CalculadoraDeSalarios. 
Até aí tudo bem. Mas será que a CalculadoraDeSalariosPlano2013 
é uma  CalculadoraDeSalariosPlano2005º Ou seria apenas uma 
CalculadoraDeSalarios? 

Essa questão semântica é um dos aspectos que podemos tratar melhor com um 
decorador, mas não ficamos limitados a isso. Porém, como veremos ainda bastante 
sobre decoradores, nesse momento o aspecto semântico já nos vale a análise. Por 


isso, vamos olhar como resolvê-lo usando composição em vez de herança. 


Decorator 





Cliente public class CalculadoraDeSalariosPlano2013 
Olnject implements CalculadoraDeSalarios ( 


CalculadoraDeSalarios calculadora; 





CalculadoraDeSalariosPlano2005 delegate; 
publio: void onloulart) ( — —+> public double calculaSalario(...X 


calculadora.calculaSalario(...); double s = delegate.calculaSalario(...); 




















Figura 6.5: Usando composição em vez de herança 


Agora com esse arranjo, temos uma leitura correta das classes envolvidas: 
a CalculadoraDeSalariosPlano2013 é uma CalculadoraDeSalarios e 
para executar a sua tarefa usa a CalculadoraDeSalariosPlano2005. Ótimo, 
problema semântico resolvido, mas será que um decorator é só um nome bonitinho 
para a máxima “quando possível, use composição em vez de herança"? Obviamente 
que não, e agora que entendemos a estrutura do decorador, veremos em que situa- 
ções ele nos será muito útil. 


6.4 VINCULAÇÃO DINÂMICA ENTRE O OBJETO DECORADO E 
SEU DECORADOR 


Enquanto no exemplo que acabamos de ver a ligação entre os objetos foi definida 
em tempo de desenvolvimento, utilizando a linguagem de programação, a funcio- 
nalidade que veremos a partir da CDI vincula os objetos em tempo de execução. 
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Na verdade, essa é uma característica do próprio padrão de projeto decorator, não é 
apenas usar composição, é fazer isso com a aplicação rodando. 

O funcionamento do decorador lembra muito o do interceptador. A diferença 
é que, neste último, a interceptação é feita de forma genérica, para adicionar à re- 
quisição requisitos não funcionais, como segurança; já no decorador adicionamos 
funcionalidades de negócio, tanto é que o decorador precisa ter o mesmo tipo do 
objeto decorado. 

Quando a CDI vai injetar um determinado objeto na classe cliente, ela verifica se 
não existe um decorador com tipo compatível, se tiver, esse decorador é passado no 
lugar do objeto original, e o original é injetado dentro do decorador, e dentro deste 
passa a ser chamado de delegate. Vejamos um exemplo prático. 


OInject 
private CalculadoraDeSalarios calculadoraDeSalarios; 


Aqui temos um código já conhecido, que nada mais é do que um cliente da in- 
terface CalculadoraDeSalarios recebendo-a do contexto CDI. Agora vamos 
analisar a implementação da CalculadoraDeSalariosPlano2013, que é um 
decorator. 


ODecorator 
public class CalculadoraDeSalariosPlano2013 
implements CalculadoraDeSalarios { 


@Inject @Delegate 
private CalculadoraDeSalarios delegate; 


@Inject 
private Logger logger; 


@Override 
public double calculaSalario(Funcionario funcionario){ 


logger.info("Delegate plano 2013"); 
double salario = delegate.calculaSalario(funcionario); 


return salario * 1.1; 
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Nesse exemplo, vamos considerar que depois de muita negociação com os funci- 
onários, a empresa onde trabalhamos decidiu que o plano de salários de 2013 apenas 
irá conceder um aumento de 10% (dez porcento) sobre o plano anterior. Em vez de 
criarmos uma nova implementação da interface CalculadoraDeSalarios, uti- 
lizamos a existente, que já está testada, e adicionamos ao retorno do seu cálculo o 
percentual de aumento estipulado. 

O interessante de analisarmos em um decorador é o ponto de injeção anotado 
com QDelegate. Perceba que, fora essa anotação, este é um ponto de injeção co- 
mum, onde definimos o tipo que desejamos e anotamos com EInject. Podemos 
adicionar aí também qualquer qualificador que desejarmos, e ao fazer isso estaremos 
especificando mais em quais casos desejamos que o decorador seja utilizado. 

O funcionamento é simples, o decorador será utilizado para substituir o ob- 
jeto original toda vez que seu delegate combinar com o que a classe cliente 
espera que seja injetado. Em outras palavras, se a classe cliente espera uma 
CalculadoraDeSalarios com qualificador eDefault e nosso decorador sabe 
decorar um objeto com o mesmo tipo, então ele será passado à classe cliente, e o 
objeto original será seu delegate. 

Se quisermos que nosso decorador atue sobre qualquer 
CalculadoraDeSalarios, e não apenas o Default, podemos fazer a 
seguinte alteração. 


ODecorator 
public class CalculadoraDeSalariosPlano2013 
implements CalculadoraDeSalarios { 


@Inject @Delegate @Any 
private CalculadoraDeSalarios delegate; 


Agora qualquer CalculadoraDeSalarios passará a ser decorada pelo 
CalculadoraDeSalariosPlano2013. Como vimos na seção 4.2, o qualifica- 
dor @Any é praticamente um desqualificador, fazendo com que o ponto de inje- 
ção marcado com ele aceite objetos com quaisquer qualificadores, e não somente o 
Default, que sempre está implícito quando não especificamos outro. 

Uma vez que entendemos o mecanismo de “interceptação” que nosso decorador 
acaba usando para entrar no lugar dos objetos originais, podemos voltar a analisar o 
exemplo anterior, em que tínhamos a injeção de um Logger além do delegate. Isso 
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porque nosso decorador é um bean como qualquer outro, e assim pode ter também 
suas próprias dependências. Essas dependências serão resolvidas como qualquer ou- 
tra, podendo ter os mesmos problemas de ambiguidade ou não tendo quem a supra; 
podem ser interceptadas, e podem inclusive serem decoradas por um outro decora- 
dor. Só não podemos ter uma dependência cíclica, na qual pedimos para injetar, em 
uma propriedade que não o delegate, um objeto que está sendo decorado pela nossa 
classe. Cada decorador pode ter um único delegate, mas pode ter diversos pontos de 
injeção normais. Também como um bean normal, nosso decorador pode receber as 
dependências via propriedade, como no exemplo, ou com as outras vias possíveis: 
construtor e método inicializador. 

Ótimo, agora temos um decorador funcionando, mas e se quisermos mais in- 
formações sobre o bean que estamos decorando em tempo de execução? Por 
exemplo, se quisermos saber exatamente qual o seu tipo, seus pontos de inje- 
ção etc; fazemos isso via reflection em cima do delegate? Existe uma forma 
mais simples, adicionada na versão 1.1 da CDI, que é adicionar uma instância de 





javax.enterprise.inject.spi.Bean, representando o bean decorado. 
A interface Bean nos permite acessar essas metainformações que queremos sa- 
ber, e para termos acesso a ela basta adicioná-la como dependência anotando-a com 


QADecorated. 


ODecorator 
public class CalculadoraDeSalariosPlano2013 
implements CalculadoraDeSalarios 1 


OInject ODelegate @Any 
private CalculadoraDeSalarios delegate; 


OInject CDecorated 
private Bean<CalculadoraDeSalarios> bean; 


Como a própria anotação sugere, esse é o Bean que está sendo decorado, e 
através dessa interface respondemos as perguntas anteriores, e podemos inclusive 
utilizá-las para adicionar mais informações ao nosso log. 


OInject CDecorated 
private Bean<CalculadoraDeSalarios> bean; 
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@Override 
public double calculaSalario(Funcionario funcionario){ 


logger.info("Delegate plano 2013"); 
Class beanClass = bean.getBeanClass(); 
Set<InjectionPoint> injectionPoints = bean.getInjectionPoints(); 
logger. info(String.format ("Bean original: '%s' " 
+ "com injection points: 'hs'", beanClass, 
injectionPoints)); 


double salario = delegate.calculaSalario (funcionario); 


return salario * 1.1; 


Com o nosso decorador completo, falta apenas habilitá-lo, pois assim como os 
interceptadores e os beans alternativos, um decorador precisa ser ativado, seja via 
beans.xml ou via anotação. 

O arquivo beans .xm1 que habilita nosso decorador fica da seguinte maneira. 


<beans xmlns="http://xmlns.jcp.org/xml/ns/javaee" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee 
http://xmlns.jcp.org/xml/ns/javaee/beans 1 1.xsd"> 
<interceptors> 
<class> 
br.com.casadocodigo...CalculadoraDeSalariosPlano2013 


</class> 
<class>...</class> <!-- um interceptador em cada tag class --> 
</interceptors> 
</beans> 


Encurtei o nome da classe apenas para facilitar a leitura, mas se trata do nome 
completo da classe, assim como em todos os outros exemplos apresentados. Também 
como nos outros exemplos onde usamos o arquivo XML, a partir da versão 1.1 da CDI 
podemos utilizar a anotação GPriority para ativar esse recurso. Com a alteração 
a seguir não precisamos alterar o beans . xml. 


ODecorator OPriority(Interceptor.Priority.APPLICATION) 
public class CalculadoraDeSalariosPlano2013 
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implements CalculadoraDeSalarios { 


Assim como os interceptors, podemos também ordenar nossos decoradores. 
Da mesma forma que podemos ter mais de um interceptador executando em uma 
mesma requisição, podemos ter mais de um decorador. Com decoradores não pa- 
rece tão óbvio, mas se tivermos uma hierarquia de beans um pouco mais complexa, 
podemos ter um decorador em um nível mais abstrato e outro em um nível mais 
específico dessa hierarquia. Prioridades menores executam primeiro, e beans ativa- 
doscom @Priority executam antes dos ativados via arquivo XML. Além disso, os 
decoradores são chamados sempre depois dos interceptadores. 
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CAPÍTULO 7 


Definindo Estereótipos e 
diminuindo o acoplamento 
utilizando Eventos 


Agora que já sabemos sobre qualificadores, mais especificamente beans nomeados, 
escopos e interceptadores, podemos ver uma ferramenta muito útil da CDI que é a 
criação de estereótipos. 

Além disso, veremos também neste capítulo como utilizar Eventos, uma funci- 
onalidade que nos dará a possibilidade de estender nossa aplicação com baixíssimo 
acoplamento. Provavelmente durante a leitura você lembrará de situações nos siste- 
mas em que trabalha em que a utilização de eventos diminuiria o acoplamento na 
comunicação entre classes, módulos, e até mesmo sistemas diferentes. 
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7.1 DEFININDO ESTEREÓTIPOS 


Quando alguém fala que uma determinada pessoa é um nerd, que imagem vem à 
sua cabeça? Talvez uma pessoa pequena, de óculos, quieta, inteligente, e provavel- 
mente com um notebook por perto. Se você pensou em algo parecido, sabe o que 
é um estereótipo. Podemos pensar em diversos exemplos diferentes, mas o signifi- 
cado é sempre o mesmo: uma generalização de características comuns, uma imagem 
preconcebida de algo. 

Até aqui vimos diversas configurações que podemos fazer em nossos beans, tais 
como definir um nome, um escopo, qualificadores e interceptadores. À primeira 
vista não parece um trabalho muito complicado, e de fato não é, mas podemos sim- 
plificar essas configurações criando um estereótipo para os beans. Para servir de 
base, vamos relembrar o exemplo da classe CalculadoraImpostosBean que vi- 


mos na seção 5.2. 


ONamed ORequestScoped 
public class CalculadoraImpostosBean { ... } 


Agora vamos pensar no nosso sistema de uma forma mais abstrata. Temos um 
sistema que trata o RH e folha de pagamentos da nossa empresa, e como já vimos 
pelos diversos exemplos nele existem diversas calculadoras diferentes, uma de im- 
postos, outra de salário e uma outra de folha de pagamento. Além disso, podemos 
ter ainda calculadoras simuladas para, por exemplo, serem utilizadas em um estudos 
de impacto financeiro quando um novo plano de cargos e salários for proposto. 

Podemos perceber que o termo “calculadora” é recorrente no nosso sistema, as- 
sim como CRUDs, ou cadastros de tabelas básicas pode ser comum no projeto que 
você trabalha hoje. Quando pensamos em um termo significativo, uma espécie de 
abstração comum a vários locais do sistema, geralmente pensamos em interfaces. É 
possível até definirmos uma interface para as calculadoras também, mas esse não 
será o foco aqui. Nosso objetivo é ver de forma parecida os beans que manipulam as 
calculadoras, os controladores que injetam as calculadoras propriamente ditas. Isso, 
no entanto, não significa que não possamos aplicar o mesmo raciocínio às imple- 
mentações das calculadoras, mas trabalhando com os controladores teremos mais 
mecanismos a analisar. 

Olhando especificamente para nosso CalculadoraImpostosBean, mas en- 
xergando a abstração de todos os CalculadoraXYZBean, percebemos que to- 
dos eles possuem nome e escopo. É um começo, mas podemos ir além. Podería- 
mos, por exemplo, definir que esses beans devem ser auditados, usando a anotação 


134 


Casa do Código Capítulo 7. Definindo Estereótipos e diminuindo o acoplamento utilizando... 





GAuditavel que vimos na seção 6.1, e assim ficaria registrado no log da aplicação 
quem anda executando o quê. O resultado seria algo como o código a seguir. 


ONamed ORequestScoped CAuditavel 
public class CalculadoraImpostosBean { ... + 


Agora pensando um pouco mais em questões de infraestrutura, poderíamos ter 
um interceptador geral que, diferente do ligado à anotação GAuditavel, que trata 
mais de auditoria de que coisas mais restritas, lidasse com questões gerais genéricas 
da aplicação, como qual método está sendo chamado, qual a URL atual, e outras 
informações não relacionadas ao negócio. Esse interceptador estaria vinculado a 
uma anotação que definimos agora: GRastreavel. Tanto seu código quanto o do 
interceptador não importam, pois estamos interessados na semântica apenas. Feito 
isso, se olharmos nosso bean novamente, veremos que a quantidade de anotações já 
incomoda. 


ONamed ORequestScoped 
OAuditavel ORastreavel 
public class CalculadoraImpostosBean { ... } 


O pior desse cenário não é nem o tanto de anotações em cima da classe, e sim 
a possibilidade de esquecermos de definir o mesmo leque de anotações quando es- 
tivermos definindo o CalculadoraxXYZBean. Ainda mais agora que estamos de- 
finindo interceptadores genéricos que servem a questões de infraestrutura, como o 
GRastreavel. Essas geralmente são as primeiras coisas que são esquecidas con- 
forme o sistema cresce. Um desenvolvedor lembra de colocar essas anotações, o 
outro não, e o quando temos um problema para analisar o log está inconsistente. 

Para evitar esses problemas, podemos definir uma anotação que resume tudo 
isso. Podemos, por exemplo, chamá-la de ECalculadoraBean, e ela terá o seguinte 
código. 


import javax.enterprise. inject.Stereotype; 


OStereotype 
ORetention(RetentionPolicy.RUNTIME) 
OTarget (ElementType.TYPE) 

public QGinterface CalculadoraBean { 


} 


Aqui, ainda, temos a definição mínima do nosso estereótipo. Estamos usando 








@Target (TYPE), mas também podemos combinar com os targets METHOD e 
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FIELD. Para que o estereótipo CalculadoraBean seja um resumo de todas aquelas 
anotações, temos que colocá-las nele. 


import javax.enterprise.inject.Stereotype; 


OStereotype 

ONamed ORequestScoped 

OAuditavel ORastreavel 
ORetention(RetentionPolicy.RUNTIME) 
OTarget (ElementType.TYPE) 

public QGinterface CalculadoraBean { 


} 


E muita coisa junta, mas agora temos um condensado de todas as configurações 
que desejamos colocar nos beans desse tipo. Agora é só anotar nosso alvo com esse 
estereótipo. 


@CalculadoraBean 
public class CalculadoraImpostosBean { ... + 


De agora em diante, se quisermos adicionar um novo interceptador em todos os 
beans dessa “família”, basta adicionar no estereótipo. Ok, muito interessante, mas e 
seo bean CalculadoraFolhaDePagamentoBean estiver em uma tela mais com- 
plexa que a responsável por calcular impostos, e por isso precisarmos de um escopo 
mais apropriado como EConversationScoped? Não tem problema, pois o este- 
reótipo define o escopo padrão, podendo ser sobrescrito pelo bean que o utilizar. 


CCalculadoraBean 

CConversationScoped 

ONamed ("calculadoraFolhaBean") 
CUmNovoQualificadorQualquer 
OMaisUmIinterceptorBinding 

public class CalculadoraFolhaDePagamentoBean { ... 5 


Como podemos ver, as configurações do estereótipo não são limitadoras, são pa- 
dronizadoras, podendo ser estendidas pelo bean cliente. Sempre que possível, tente 
padronizar suas configurações para evitar inconsistências. Apesar de termos anali- 
sado um estereótipo para a camada “controladora” do MVC, como estamos falando 
de CDI, podemos definir um estereótipo para qualquer lugar da nossa aplicação, 
como na implementação das calculadoras. 
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Podemos, por exemplo, definir um estereótipo como GAlternative para que 
seja usado nas simuladoras de cálculo. 


OStereotype 

OAlternative 

ORastreavel 
ORetention(RetentionPolicy.RUNTIME) 
OTarget (ElementType.TYPE) 

public Qinterface Mock { 

} 


E podemos ainda combinar estereótipos simplesmente anotando um estereótipo 
com outro. 


@Stereotype 

@CalculadoraBean @Mock 
@Retention(RetentionPolicy.RUNTIME) 
OTarget (ElementType.TYPE) 

public Qinterface CalculadoraMockBean { 


} 


Assim qualquer bean anotado com @CalculadoraMockBean terá um nome 
padrão, será @RequestScoped, Q@Auditavel e @Rastreavel, e também 
GAlternative. Certamente é uma forma muito flexível de organizar os beans com 
características semelhantes. 


Model: estereótipo de série 


Aprendemos a criar nossos próprios estereótipos, mas caso queiramos apenas 
um que defina o escopo request como padrão e que o bean que o utilizar será nome- 
ado, podemos utilizar o estereótipo Gjavax.enterprise.inject .Model. Seu 





objetivo é disponibilizar, sem a necessidade de codificação alguma, um estereótipo 
que sirva para os beans da camada “model” do MVC. 


7.2 UTILIZANDO EVENTOS PARA OBTER UM BAIXÍSSIMO 
ACOPLAMENTO 


Quando pensamos em CDI, a primeira funcionalidade que nos vem à cabeça é a 
resolução de dependências. Este é o assunto mais buscado sobre a especificação, 
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mas nesta seção veremos como o mecanismo de eventos pode ser de grande valia 
para nossas aplicações. 

A utilização é extremamente simples, mas precisamos pensar nas funcionalida- 
des dos nossos sistemas de uma forma diferente. Para nosso estudo, vamos conside- 
rar a gestão de funcionários da nossa empresa. Imagine que na empresa temos di- 
versos sistemas, e que para acessar esses sistemas os funcionários precisam, além de 
seu login e senha, estarem com sua situação funcional ativa dentro da empresa. Ou 
seja, quando o funcionário for desligado, seu acesso deve ser cortado nos sistemas. 
Semelhantemente, podemos criar o acesso aos sistemas quando um novo funcioná- 
rio for contratado, então logo que ele sair do RH da empresa, já poderá começar a 
trabalhar. 

Quais serão os sistemas que os funcionários da empresa utilizam vai depender 
de cada ramo de atuação. Por exemplo, em uma empresa de desenvolvimento de 
software, os funcionários terão acesso ao repositório de código e à ferramenta de 
controle de issues. Em outras empresas talvez tenhamos que dar acesso ao ERP, ou 
qualquer sistema que você possa imaginar. Agora pense como criar esses acessos 
logo depois do cadastro do funcionário, e como removê-los no desligamento. Será 
que algo parecido com o pseudocódigo abaixo é uma boa alternativa? 


public void cadastrarFuncionario (Funcionario funcionario)( 
//lógica de ativação do funcionário 
funcionario.setStatus (ATIVO); 
entityManager.persist (funcionario); 


criaUsuarioGit (funcionario); 
criaUsuarioIssueTracker (funcionario); 
criaUsuarioERP (funcionario); 


Como podemos perceber, acabamos criando um acoplamento entre a gestão de 
funcionários os diversos sistemas que eles utilizarão no seu dia a dia. Pode não pa- 
recer algo tão absurdo, mas não é o desejado, visto que esses sistemas podem mudar. 
Podemos trocar o issue tracker utilizado, podemos passar a usar algum novo sistema 
ou deixar de criar usuários no ERP para todos os funcionário, deixando apenas para 
aqueles que de fato precisarão operar esse sistema. A cada mudança desse tipo, tere- 
mos que alterar o método de cadastro do funcionário, mesmo sem qualquer alteração 
na lógica de ativação de funcionário do ponto de vista do RH. Isso nos dá um forte 
indício de que devemos mudar algo. 
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Uma evolução nesse cenário seria definirmos algum tipo de interface que abs- 
traia essa criação de usuários. 


public interface GerenciadorDeAcesso { 
void criaUsuario(Funcionario funcionario) 


public class GerenciadorDeAcessoGit implements GerenciadorDeAcesso {...} 
public class GerenciadorDeAcessoERP implements GerenciadorDeAcesso 1...) 
//outras implementações 


E agora podemos alterar nossa gerenciadora de funcionários para utilizar essa 
abstração 


public class GerenciadorFuncionarioBean { 
private List<GerenciadorDeAcesso> gerenciadoresAcesso = 
Arrays .asList( 
new GerenciadorDeAcessoGit(), 
new GerenciadorDeAcessoERP(), 
new GerenciadorDeAcessoIssueTracker()); 


public void cadastrarFuncionario(Funcionario funcionario){ 
//lógica de ativação do funcionário 
funcionario.setStatus (ATIVO); 
entityManager.persist (funcionario); 


for (GerenciadorDeAcesso gerenciador : gerenciadoresAcesso)( 
gerenciador.criaUsuario (funcionario); 


Dessa maneira é possível alterar muita coisa apenas criando novas implementa- 
ções de GerenciadorDeAcesso e adicionando ou removendo instâncias da lista 
gerenciadoresAcesso. Ainda podíamos evoluir nossa solução criando uma es- 
pécie de federação de gestores de usuários, tratando essa coleção como se fosse um 
único objeto, e deixando que esse objeto delegasse cada chamada aos elementos da 
lista. Isso com certeza melhoraria ainda mais a solução, mas ainda podemos ter no- 
vas situações fugindo do nosso controle. 

Vamos supor que, por questões legais, nossa empresa tenha que informar ao 
INSS quando realizar uma nova contratação. Seria uma situação muito parecida com 
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a criação de usuários feita através das implementações de GerenciadorDeAcesso, 
mas criar uma nova implementação dessa interface para informar ao INSS seria uma 
quebra na semântica da interface. Até porque teremos outros métodos de concessão 
de permissões que a implementação do INSS não necessitaria. E agora? Como re- 
solver esse problema? 

Poderíamos criar uma interface ancestral da GerenciadorDeAcesso, com 
apenas métodos como criarUsuario e removerUsuario e então criar a imple- 
mentação do INSS baseado nela. Mas será que precisamos mesmo fazer essas coisas 
dentro do método de negócio? A resposta é não, e usaremos eventos para resolver 
esses problemas. A vantagem é que provavelmente também estaremos preparados 
para qualquer outra nova operação que tenhamos de fazer ao contratar um funcio- 
nário, sem correr o risco de quebrar a semântica das interfaces que temos, e sem ter 
que alterá-las para isso. 


import javax.enterprise.event.Event; 


public class GerenciadorFuncionarioBean { 


OInject 
private Event<Funcionario> eventoFuncionarioCadastrado; 


public void cadastrarFuncionario(Funcionario funcionario)( 
//lógica de ativação do funcionário 
funcionario.setStatus (ATIVO); 
entityManager.persist (funcionario); 


eventoFuncionarioCadastrado.fire(funcionario); 


Criamos um objeto que lança eventos relacionados ao tipo Funcionario, 


e o chamamos de | eventoFuncionarioCadastrado, que é do tipo 





javax.enterprise.event.Event. Com isso, agora nosso método de ne- 





gócio não depende de qualquer GerenciadorxYyz, ele simplesmente lança um 
evento escutável por qualquer objeto do contexto CDI. Assim, se algum objeto 
quiser fizer alguma operação no cadastramento de um novo funcionário, basta 
escutar esse evento. O acoplamento entre quem lança o evento e quem o escuta é 
praticamente zero. 
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7.3 OBSERVADORES SÍNCRONOS DE EVENTOS 


Para um objeto receber a notificação de que um novo Funcionario foi admitido, 
basta escutar o evento lançado pelo GerenciadorFuncionarioBean. 


import javax.enterprise.event.0Observes; 
public class GerenciadorDeAcessoGit { 


public void criaUsuarioGit (O0Ubserves Funcionario funcionario)f 


A implementação, como acabamos de ver, é bem simples. O melhor é que nem 
precisamos definir qualquer interface, uma vez que não existe qualquer vínculo en- 
tre GerenciadorFuncionarioBean e GerenciadorDeAcessoGit. Se existe 
algum vínculo, é totalmente indireto, pois por padrão os observadores são síncro- 
nos. Assim, caso um observador demore demais para processar algo, ou lance uma 
exceção, quem lançou o evento será impactado, e o acoplamento entre os dois se 
restringe a isso. 

Não podemos no entanto diminuir demais essa característica, visto que em um 
cenário Java EE, onde a transação é gerenciada pelo container, o método que lança 
o evento e o que o observa executam na mesma transação. Assim, a exceção lançada 
por um observador pode causar rollback em toda a transação, que envolve o mé- 
todo de negócio e todos os observadores. Essa pode ser uma característica desejável, 
nos permitindo validar algo via observador, mas pode não ser. Nesse caso a melhor 


opção seria utilizar um evento assíncrono. 


7.4 EVENTOS E QUALIFICADORES 


O exemplo de notificador e observador que vimos foi extramente simples: envolve 
apenas um evento do tipo Funcionario. Mas para que esse mecanismo seja efi- 
caz, precisamos conseguir diferenciar, por exemplo, um evento de contratação de 
funcionário de um evento de desligamento, e para fazer isso, utilizamos qualificado- 
res, da mesma forma que fazíamos para acabar com a ambiguidade na resolução de 
dependências. 

Para demonstrar, vamos alterar nosso exemplo para distinguirmos eventos de 
contratação e eventos de demissão de funcionários. Os qualificadores utilizados são 
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criados exatamente da mesma forma que os qualificadores vistos na seção 4.2, usados 
na resolução de dependências, por esse motivo não é necessário vermos o código 
aqui. 


public class GerenciadorFuncionarioBean { 


OInject CContratacao 
private Event<Funcionario> eventoContratacao; 


OInject CDemissao 
private Event<Funcionario> eventoDemissao; 


public void cadastrarFuncionario(Funcionario funcionario)( 


eventoContratacao.fire(funcionario); 


public void demitirFuncionario(Funcionario funcionario)( 


eventoDemissao.fire (funcionario); 


Várias classes podem observar o mesmo evento, mas para facilitar vamos colocar 


alguns observadores, um abaixo do outro. 


public void escutaContratacao(@0bserves @Contratacao Funcionario f){ 


} 


public void escutaDemissao(@0bserves @Demissao Funcionario f){ 


} 


public void escutaQualquerEventoDeFuncionario(ODbserves Funcionario f){ 


Enquanto os dois primeiros observadores são específicos para cada tipo 
de evento de Funcionario, o terceiro observará qualquer evento do tipo 
Funcionario, seja @Contratacao, @Demissao ou outra qualidade de evento de 
funcionário que venha a ser criado. Mas nosso exemplo ainda pode ser incremen- 
tado. Iremos adicionar um outro tipo de desligamento de funcionário, a aposentado- 
ria. Agora ao desligar um funcionário precisaremos definir o tipo de desligamento. 
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public class GerenciadorFuncionarioBean { 
private TipoDesligamento tipoDesligamento; 


@Inject 0Aposentadoria 
private Event<Funcionario> eventoAposentadoria; 


OInject CDemissao 
private Event<Funcionario> eventoDemissao; 


public void desligarFuncionario(Funcionario funcionario)( 


if (tipoDesligamento == TipoDesligamento.APOSENTADORIA)( 
eventoAposentadoria.fire(funcionario); 


} 
else if(tipoDesligamento == TipoDesligamento.DEMISSAO)( 
eventoDemissao.fire(funcionario); 


Esse exemplo funciona, mas poderíamos trocar os dois pontos de injeção de 
eventos por apenas um, e qualificá-lo dinamicamente, parecido com o que fizemos 
na seção 4.8 quando vimos o lookup programático. Pode parecer que fica mais difícil, 
mas isso nos dá muita possibilidade de tomara de decisão em tempo de execução. 


public class GerenciadorFuncionarioBean { 
private TipoDesligamento tipoDesligamento; 


OInject 
private Event<Funcionario> eventoDesligamento; 


public void desligarFuncionario (Funcionario funcionario)( 


Annotation qualificador = null; 
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if(tipoDesligamento == TipoDesligamento.APOSENTADORIA)L 
qualificador = new AnnotationLiteral<Aposentadoria>() 1); 

} 

else if(tipoDesligamento == TipoDesligamento.DEMISSAO){ 
qualificador = new AnnotationLiteral<Demissao>(){}; 


Event<Funcionario> eventoQualificado = eventoDesligamento 
.select (qualificador); 
eventoQualificado.fire(funcionario); 


Fizemos uso da classe utilitária javax.enterprise .util.AnnotationLiteral, 


que deve ser tipada com a anotação que desejamos represen- 
tar. Logo depois, de posse do objeto qualificador, que é do 
tipo java. lang.annotation.Annotation, usamos o método 





select (Annotation) do objeto Event. É como se estivéssemos saindo 
de um select sem where para um com where qualificador = q. Obviamente nesse 
exemplo q representa o qualificador definido dinamicamente, dentro do nosso 
método. Feita essa alteração, os observadores não mudam absolutamente nada, pois 
os eventos continuarão sendo qualificados. 


Qualificadores de eventos com atributos 


Novamente igual vimos na seção 4.2, podemos definir atributos nos qualifica- 
dores utilizados. Esses atributos também servem para relacionar o notificador e o 
observador do evento, a menos que a propriedade do qualificador esteja anotada 
com ENonbinding; exatamente como acontece quando usamos um qualificador 
para injetar dependências. Por exemplo, a partir de agora passaremos a usar o qua- 
lificador Desligamento. 


OTarget (LTYPE, FIELD, METHOD, PARAMETERJ) 
ORetention(RetentionPolicy.RUNTIME) 
OQualifier 
public Ointerface Desligamento { 
TipoDesligamento value() default TipoDesligamento.APOSENTADORIA; 


Vamos alterar mais uma vez nosso exemplo para usarmos apenas um qualifica- 
dor, e fazer a distinção via atributo. Utilizaremos a mesma enum que usamos nos 
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ifs anteriores. Para não termos códigos muito extensos vamos olhar apenas como 
injetar os produtores de eventos na nossa classe. 


OInject ODesligamento (TipoDesligamento.APOSENTADORIA) 
private Event<Funcionario> eventoAposentadoria; 


OInject ODesligamento(TipoDesligamento.DEMISSAO) 
private Event<Funcionario> eventoDemissao; 


//e os observadores ficam como abaixo 


public void observaAposentadoriaFuncionario (O0bserves 
ODesligamento (APOSENTADORIA) Funcionario funcionario)( 


} 
public void observaDemissaoFuncionario(@0bserves 
ODesligamento (DEMISSAO) Funcionario funcionario)f 


Feito isso, poderíamos usar cada instância dessa como já vimos nos exemplos 
anteriores. Porém o mais interessante seria vermos como qualificar dinamicamente 
nosso produtor de eventos, assim como acabamos de fazer quando tínhamos dois 
qualificadores. O problema é que não conseguimos fazer isso de uma maneira sim- 
ples, pois agora temos que devolver a anotação no método value () do nosso objeto 
qualificador. Parte disso pode ser feita com classes aninhadas, mas usaremos uma 
classe servirá para substituir a AnnotationLiteral pois dessa maneira o código 
fica mais organizado. 


public abstract class DesligamentoQualifier 
extends AnnotationLiteral<Desligamento> 
implements Desligamento ( 
private TipoDesligamento tipoDesligamento; 
public DesligamentoQualifier(TipoDesligamento tipoDesligamento)( 


this.tipoDesligamento = tipoDesligamento; 


public TipoDesligamento value() { 
return tipoDesligamento; 
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E agora voltamos mais uma vez à versão em que temos apenas uma instância de 





Event, e qualificaremos isso de forma dinâmica, mas agora usando qualificadores 
com propriedades. 


public class GerenciadorFuncionarioBean { 
private TipoDesligamento tipoDesligamento; 


OInject 
private Event<Funcionario> eventoDesligamento; 


public void desligarFuncionario (Funcionario funcionario)( 


Annotation qualificador = null; 
if(tipoDesligamento == TipoDesligamento.APOSENTADORIA)L 
qualificador = new DesligamentoQualifier(APOSENTADORIA) LJ; 


} 
else if(tipoDesligamento == TipoDesligamento.DEMISSAO){ 


qualificador = new DesligamentoQualifier (DEMISSAO)(); 


Event<Funcionario> eventoQualificado = eventoDesligamento 
.select (qualificador); 
eventoQualificado.fire(funcionario); 


7.5 OBSERVADORES ASSÍNCRONOS DE EVENTOS 


Já vimos como funciona o mecanismo de eventos, e vimos também que, por padrão, 
os observadores são síncronos. Porém, como foi dito, a execução lenta de um ob- 
servador pode impactar na execução do método de negócio, e em alguns casos não 
há o que ser feito, precisamos realizar uma tarefa que é lenta, mas certamente não 
queremos degradar o funcionamento do método notificador. A saída para isso é a 
utilização de observadores assíncronos. 
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Como ainda vamos analisar no capítulo 8, a CDI não sobrepõe funcionalidades 
de outras especificações do Java EE. E o suporte a métodos assíncronos já é tratado 
pela especificação de EJBs, assim sendo, utilizaremos esse suporte para criarmos ob- 
servadores assíncronos. 

Logo, somente com CDI, não conseguimos executar observadores assíncronos 
em um servlet container como Tomcat ou Jetty. Isso, é claro, sem alguma extensão 
que adicione essa funcionalidade fora de um servidor de aplicação como JBossAS 
(Wildfly) ou Glassfish. Sobre extensões, nos aprofundaremos no capítulo 9. Por 
enquanto apenas utilizaremos a funcionalidade disponível no Java EE. 

Agora que sabemos que essa funcionalidade é na verdade um empréstimo da 
especificação de EJBs, vamos ver como implementamos um observador assíncrono. 


OStateless 
public class ObservadorDeFuncionarios { 


CAsynchronous 
public void observaDemissaoFuncionario (OUbserves 
ODesligamento (DEMISSAO) Funcionario funcionario)f 


Basta que nosso beans seja um EJB e anotar nosso observador com 
Ajavax.ejb.Asynchronous e o método passa a executar em um contexto di- 
ferente do método notificador. Considerando o contexto transacional do método 


de negócio, o observador assíncrono funciona como se estivesse anotado com 














Gjavax.ejb.TransactionAttribute (REQUIRES NEW). Em outras palavras, 





o observador não provoca rollback no método notificador. 

Sabendo dessa funcionalidade, pode parecer que encontramos uma bala de 
prata, uma vez que o observador pode demorar sem impactar o notificador. Já sabe- 
mos também que uma exceção no observador também não vai atrapalhar o método 
de negócio ou os demais observadores. Mas temos que nos lembrar que em alguns 
casos, o observador estar na mesma transação que o notificador é o desejável. 

Vamos imaginar o cenário de um sistema de vendas, onde ao vender um item 
é lançado um evento, que é capturado pelo módulo de estoque para que este decre- 
mente a quantidade do produto. Agora, imaginemos que ocorra um problema no 
módulo de estoque. Pode ser interessante que a exceção chegue à operação de venda 


147 


7.6. Injetando dependências nos observadores Casa do Código 





para que o estoque não fique inconsistente. Então a operação da venda pode ser re- 
petida, e se não houver uma nova exceção, a transação ocorre de forma consistente. 

Em um cenário como o descrito, caso estejamos usando um observador assín- 
crono, ocorrendo uma exceção no módulo de estoque, teríamos que voltar ao mó- 
dulo de compra para desfazer a venda. Nesse caso, se o cliente já foi embora, não será 
possível refazer a operação. Teríamos que notificar o problema de alguma forma para 
poder tratá-lo de forma manual. Em resumo, em algumas situações desejamos que o 
observador seja síncrono e em outras assíncrono, não existe um único remédio para 
todos os males. 


7.6 INJETANDO DEPENDÊNCIAS NOS OBSERVADORES 


Um observador de evento é um bean comum, dessa maneira, é possível injetar qual- 
quer dependência nele. Porém, temos a opção de fazer algo bem parecido com o que 
vimos nos métodos produtores, que é receber uma dependência como parâmetro do 
método. 

Podemos criar o bean ObservadorDeFuncionarios e injetar nele um 
Logger como poderíamos fazer em qualquer outra parte do sistema. 


public class ObservadorDeFuncionarios 1 
OInject 
private Logger logger; 


public void observaFuncionario(00bserves Funcionario funcionario)f 
logger. info("Recebendo evento do funcionario {}", funcionario); 


Mas podemos também receber o Logger como dependência no próprio mé- 
todo observador. As vantagens de se fazer isso são as mesmas comentadas na seção 
5.1 quando vimos os métodos produtores. Basicamente quando colocamos as de- 
pendências no método, fica claro o que é necessário para o observador funcionar. É 
como uma documentação a nível de assinatura de método. 


public class ObservadorDeFuncionarios { 
public void observaFuncionario(O0bserves Funcionario funcionario, 
Logger logger){ 


logger. info("Recebendo evento do funcionario {}", funcionario); 
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Cada método observador só pode ter um parâmetro anotado com @Observes, 
os demais parâmetros serão pontos de injeção. 
Usando a interface EventMetadata 


Utilizando a injeção de dependências nos parâmetros dos métodos observa- 
dores, podemos utilizar mais uma funcionalidade da CDI 11, que é a interface 








javax.enterprise.inject.spi.EventMetadata. Essa interface possui ape- 
nas três métodos, como podemos ver a seguir. 


public interface EventMetadata { 


javax.enterprise.inject.spi.InjectionPoint getInjectionPoint(); 
java.util.Set<Annotation> getQualifiers(); 
java.lang.reflect.Type getType 0); 


O primeiro método devolve o InjectionPoint referente ao objeto 





Event<T> que lançou o evento, ou pode retornar null se o evento foi dispa- 








rado diretamente via BeanManager.fireEvent (Object objetoDoEvento, 
Annotation... qualificadores). 

Os outros dois métodos retornam respectivamente os qualificadores e o tipo do 
evento disparado. Isso porque não necessariamente esses valores serão exatamente 
iguais aos que estão configurados no método observador. Como já vimos, nosso ob- 
servador pode ter menos qualificadores que o evento original; assim também como 
o tipo pode ser compatível, sem ser o mesmo. 


Diferente de quando injetamos o Logger tanto no bean quanto no método, o 





EventMetadata só pode ser injetado no método observador. 


public void observaFuncionario(00bserves Funcionario funcionario, 
Logger logger, EventMetadata eventMetadata)f 


logger. info("Recebendo evento do funcionario {}", funcionario); 
InjectionPoint injectionPoint = eventMetadata.getInjectionPoint(); 
if(injectionPoint != null) 
logger. info("Evento disparado por (J", 
injectionPoint.getMember()); 
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Apesar de estarmos finalizando o capítulo, ainda veremos um pouco mais sobre 





eventos, e um exemplo real do uso de BeanManager.firel 
onde aprenderemos sobre CDI e JSF. 
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CAPÍTULO 8 


A relação da CDI com as demais 
especificações Java EE 


O Java EE é uma coleção de diversas especificações, como EJB, JPA, JSF, Beans Vali- 
dation, JMS, JTA, e mais uma dúzia de siglas que às vezes assusta quem está come- 
çando a trabalhar com Java EE. Mas a boa notícia é que são especificações simples de 
usar, e a cada versão do Java EE elas ficam mais simples ainda. No meio de todas es- 
sas especificações, temos a CDI, que acaba funcionando como um sistema nervoso, 
ou mais precisamente o cérebro do Java EE, pois está presente em praticamente qual- 
quer outra especificação moderna. 

Algumas especificações são praticamente parte da CDI, sendo difícil utilizar esta 
sem usar os recursos das demais. Um exemplo é a JSR 318, Interceptors 1.2, do qual 
até já vimos parte de seus funcionamento na seção 6.1. 

Existe também a especificação “Dependency Injection for Java” (JSR 330), que 
tem o nome bem parecido com a própria CDI (“Contexts and Dependency Injection 
for the Java EE platform”). Mas essa, porém, não passa de um especificação-anã, 
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que apenas padroniza as anotações do pacote javax.inject como @Inject e 
GQualifier. Ela serve para outros provedores de injeção de dependência, como 
Spring, utilizem as mesmas anotações que as utilizadas pelas implementações de 
CDI, como o Weld, mesmo não implementando a mesma especificação. 

A CDI foi introduzida no Java EE 6, e como estava sendo desenvolvida em pa- 
ralelo com diversas outras especificações, algumas delas, como o JSF 2.0, não eram 
totalmente compatível com a nova especificação. Porém, agora no Java EE 7, essas in- 
tegrações foram amadurecidas, fechando pequenas lacunas que existiam nas versões 
anteriores. 

Em todos as integrações, a CDI funciona basicamente como um injetor de re- 
cursos da outra outra especificação, por isso vamos nos ater neste capítulo a algumas 
integrações que são mais perceptíveis no dia a dia. 


8.1 RELAÇÃO ENTRE CDI E EJB/JPA 


Quando utilizamos CDI e JPA dentro de um servidor de aplicações, que também tem 
disponível a implementação de EJB, nem nos damos conta de estar usando essa úl- 
tima quando vamos salvar um objeto no banco de dados. Apesar de termos passado 
por JPA apenas de passagem em alguns momentos, por este não ser o foco deste livro, 
sabemos que só conseguimos escrever no banco de dados utilizando JPA se existir 
uma transação ativa. Sem transações é possível apenas ler dados. 

Acontece que quando temos EJBs disponíveis, podemos fazer algo tão simples 
quanto o seguinte para salvar um objeto. 


OStateless 

public class FuncionarioBean ( 
OInject 
private EntityManager em; 


public void salvarFuncionario(Funcionario funcionario)( 
em.persist (funcionario); 


Basta anotar nosso bean com EStateless ou EStateful para que todos os 
métodos dentro do bean sejam automaticamente transacionais. Ou seja, no exemplo 
que acabamos de ver, o método salvarFuncionario não precisa lidar com tran- 
sações, pois isso é feito automaticamente pelo servidor. Ótimo, mas e se estivermos 
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utilizando CDI e JPA em um servlet container como o Tomcat ou Jetty? Nesse caso 
teremos que lidar com as transações manualmente, como no exemplo a seguir. 


public class FuncionarioBean ( 
OInject 
private EntityManager em; 


public void salvarFuncionario(Funcionario funcionario)( 
EntityTransaction tx = em.getTransaction(); 
tx.begin(); 
em.persist (funcionario); 
tx.commit(); 


Nos dois exemplos, consideramos que existe um produtor CDI que disponibiliza 





o EntityManager para nosso bean, assim como visto na seção 5.1. Principalmente 
para quem está acostumado à praticidade da gestão automática de transações, e viu 
como é simples fazer um interceptador com CDI (como na seção 6.1), fica a dúvida: 
por que a CDI não um interceptador pronto para gerenciar transações? A resposta 
é que, por mais que seja simples fazer isso, A CDI não oferece nada que sobreponha 
algo já disponível no Java EE. Se já temos essa funcionalidade nos EJBs, a CDI não 
oferece uma alternativa. 

Isso, no entanto, não significa que não pudéssemos criar esse interceptador 
quando formos rodar CDI e JPA fora de um servidor de aplicação, ou que não tenha- 
mos extensões prontas que nos oferecem essa funcionalidade. Ainda veremos sobre 
extensões no capítulo 9, mas elas são basicamente jars que adicionamos à nossa apli- 
cação e assim ganhamos funcionalidades que vão além da CDI padrão. 

Para nossa sorte, essa funcionalidade é tão simples de implementar que sequer 
precisamos lançar mão da funcionalidade de extensão, basta pra isso implementar 
um interceptador conforme já vimos. Um exemplo de implementação que nos daria 
essa funcionalidade é o código a seguir. 


GInterceptor OTransacional 
public class InterceptadorGerenciadorDeTransacoes { 


OInject 
private EntityManager entityManager; 
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CAroundinvoke 
public Object gerenciaTransacao (InvocationContext context) 
throws Exception { 


EntityTransaction tx = null; 

try É 
//em ambiente JTA apenas o getTransaction já lança exceção 
tx = entityManager.getTransaction(); 
tx.begin(); 
Object retorno = context .proceed(); 
tx.commit(); 
return retorno; 

} catch (RuntimeException e) { 
if(tx != null) tx.rollback(); 
throw e; 


No nosso exemplo, apenas injetamos no interceptador o mesmo 
EntityManager que está disponível no bean, e então fizemos a gestão ma- 





nual da transação. Conforme o comentário no código, temos que tomar cuidado 
para não colocar para executar esse interceptador dentro do servidor de aplicação, 
pois lá dentro, quem cuida das transações é o container. Por isso, é interessante 
ativar esse interceptador apenas em servlet containers. 





Para nosso exemplo funcionar, precisamos que nosso EntityManager tenha 
o escopo de requisição, que é o que mais se assemelha ao escopo de transação dos 
EJBs. 


public class ProdutorEntityManager ( 


OProduces 0ApplicationScoped 
private EntityManagerFactory factory = Persistence 
.createEntityManagerFactory ("default"); 


OProduces ORequestScoped 
public EntityManager criaEntityManager( 
EntityManagerFactory factory)f 
return factory.createEntityManager (); 
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public 


ent 


void fechaEntityManager( 
ODisposes EntityManager entityManager)( 
ityManager.close(); 


Esse escopo é muito importante, pois se não o especificarmos, a CDI atribui o 


escopo dependent, e uma nova instância será criada toda vez que for solicitado. No 


nosso caso, O 





prolema seria a existência de uma instância de EntityManager den- 


tro da classe FuncionarioBean, e outra instância dentro do interceptador, fazendo 


nosso mecanismo não funcionar como o esperado. Depois de tudo, precisamos ape- 


nas usar o interceptador. 


OTransacional 


public clas 


OInject 
public 
em. 
} 
} 
OU 


public clas 
OInject 


s FuncionarioBean ( 
private EntityManager em; 


void salvarFuncionario(Funcionario funcionario) 
persist (funcionario); 


s FuncionarioBean ( 
private EntityManager em; 


OTransacional 


public 


em. 


void salvarFuncionario(Funcionario funcionario) 
persist (funcionario); 


O código do interceptor binding ETransacional não está nesse exemplo, mas 


já vimos como criá-los quando estudamos interceptadores. 


Agora se 


nossa aplicação trabalhar com mais de um banco de dados, teremos 





mais de um 


EntityManager disponível. Nesse caso, precisaremos fazer uma inje- 


ção mais elaborada no nosso interceptador para conseguirmos utilizar o objeto cor- 


reto. Como ainda não vimos como fazer isso, vamos retomar esse assunto na seção 


4.8, onde veremos como fazer injeções programáticas. 


155 


8.2. Relação entre CDI e JSF Casa do Código 





Se quisermos disponibilizar nosso interceptador para qualquer aplicação, basta 





colocar o arquivo beans.xml1 dentro da pasta META-INF do jar que irá conter 
nosso interceptador. Com isso, quando o contexto CDI iniciar na aplicação que usa 
nossos jar, por termos esse arquivo nesse lugar, o jar será considerado um pacote 
CDI, e o interceptor e qualquer outro bean que estiver dentro do jar ficará disponível 
na aplicação. 

Porém como já vimos na seção 6.1, não basta definir o interceptador, precisamos 
ativá-lo. Isso pode ser feito no arquivo beans .xm1 ou simplesmente adicionando 
a anotação GPriority ao interceptador. Mas se tivermos tanto aplicações que ro- 
dam em servlet container quando em servidores de aplicação, o mais indicado seria 
ativarmos via XML somente no ambiente correto; uma vez que a anotação já ativa o 
interceptador por padrão. 


8.2 RELAÇÃO ENTRE CDI E JSF 


O JSF 2.0 e o CDI 1.0 tiveram alguns problemas de integração, pois foram desen- 
volvidos paralelamente na época do lançamento do Java EE 6. Agora no Java EE 7, 
com JSF 2.2 e CDI 1.1, esses problemas foram superados. O único ponto que ainda 
temos algum atrito é com as anotações de escopo do JSF, que se encontram no pa- 
cote javax. faces .bean, pois elas têm a mesma função dos escopos definidos no 
pacote javax.enterprise.context. Tanto é que a documentação do JSF 2.2 já 





informa que as anotações desse pacote devem ser depreciadas em novas versões da 
especificação, e nos sugere usar as anotações do pacote CDI sempre que possível. Até 
porque, por conta dessa sobreposição, a CDI não reconhece as anotações de escopo 
do pacote do JSF. 

Utilizando as últimas verões disponíveis até o momento — JSF 2.2 e CDI 1.1 — 
não teremos os problemas de incompatibilidade, que são principalmente a incapaci- 
dade de injetarmos recursos através da CDI dentro de conversores e validadores JSF. 
De qualquer forma, mesmo utilizando as versões anteriores conseguimos contornar 
essa deficiência utilizando extensões da CDI como DeltaSpike da fundação apache 
(http://deltaspike.apache.org/jsf.html) . Porém, veremos mais de extensões no ca- 
pítulo 9, por enquanto basta sabermos que essas limitações não precisam impactar 
nossas aplicações. 

Agora que já falamos do histórico, das antigas limitações e que as novas ver- 
sões as resolveram, vamos explorar o que podemos fazer com a integração entre 


essas duas especificações. Para iniciarmos de uma forma leve, podemos criar mé- 
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todo produtores para objetos do contexto JSF que muitas vezes precisamos buscar 





via API, como por exemplo FacesContext, ExternalContext, ambos do pa- 
cote javax. faces.context,e javax.faces.application.Application 
Esses, é claro, são apenas alguns exemplos, podemos fazer isso para qualquer outro 
bean. 


public class ProdutorFaces { 


OProduces 
private FacesContext context = FacesContext.getCurrentInstance(); 


OProduces 
private ExternalContext externalContext = FacesContext 
.getCurrentInstance().getExternalContext(); 


OProduces 


private Application application = FacesContext 
.getCurrentInstance().getApplication(); 


Podemos ainda criar qualificadores representando os escopos que podemos 





acessar via ExternalContext e injetar diretamente mapas dentro dos nossos be- 


ans. 


OInject CApplicationMap 
private Map<String, Object> applicationMap; 


OInject CSessionMap 
private Map<String, Object> sessionMap; 


OInject CRequestMap 
private Map<String, Object> requestMap; 


OInject CRequestParameterMap 
private Map<String, String> requestParameterMap; 


E para disponibilizarmos esses objetos, basta incrementarmos mais nosso 
ProdutorFaces com os seguintes métodos. 


OProduces CApplicationMap 
public Map<String, Object> 
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disponibilizaApplicationMap(ExternalContext ec){ 
return ec.getApplicationMap(); 


OProduces 0SessionMap 
public Map<String, Object> disponibilizaSessionMap (ExternalContext ec){ 
return ec.getSessionMap(); 


OProduces 0RequestMap 
public Map<String, Object> disponibilizaRequestMap (ExternalContext ec){ 
return ec.getRequestMap(); 


OProduces 0RequestParameterMap 
public Map<String, String> 
disponibilizaParameterMap(ExternalContext ec){ 
return ec.getRequestParameterMap() ; 


Como acabamos de ver, é bem simples e útil fazer esse tipo de integração, e a 
única coisa que usamos foi a funcionalidade da CDI de criar produtores. Esses exem- 
plos deixam bem claro como a CDI é ao mesmo tempo abrangente — pois usamos 
com qualquer coisa dentro do Java EE —, poderosa, e o mais importante, simples. 


Observadores para eventos do JSF 


Criar produres para os objetos mais acessados do JSF é bastante simples, mas 
agora vamos dar um passo além nessa integração. Trabalhando com JSF, em alguns 
momentos precisamos interagir com o ciclo de vida de uma requisição, fazendo al- 
guma operação depois da fase Restore View ou antes da Render Response, apenas para 
exemplificar. Porém, para fazer isso não podemos usar, pelo menos não de forma 
natural, nossos beans “de negócio”, que são POJOs; e sim implementar a interface 


PhaseListener. 


public class SegurancaPhaseListener implements PhaseListener ( 
QOverride 
public void afterPhase (PhaseEvent event) { 


//verifica se o usuário está logado 
//se não estiver, envia para tela de login 
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@Override 
public void beforePhase (PhaseEvent event) { 


} 


@Override 
public PhaseId getPhaseId() { 
return PhaseId.RESTORE_VIEW; 


Nesse exemplo, criamos um listener que vai verificar se o usuário está logado ou 
não e, caso não esteja, enviá-lo à tela de login. O código que faz isso não importa, 
pois varia em cada organização. O interessante aqui é analisarmos como temos que 
fazer, e como seria interessante fazermos, como no exemplo abaixo. 


public class SegurancaListener { 


public void verificaLogin( 
@Observes @After @RestoreView PhaseEvent e){ 
//executa a lógica de checagem do login 


A vantagem do segundo exemplo, é que podemos lidar com os eventos do ciclo 
de vida do JSF da mesma forma que fazemos com qualquer outro evento, ou seja, 
dentro dos nossos beans. Uma outra limitação que contornamos com essa mudança, 
é que antes da versão 2.2 do JSF, não era possível termos pontos de injeção dentro 
dos PhaseListeners, o que nos limitava bastante. Já usando eventos CDI, mesmo 
usando JSF anterior, não tínhamos esse problema pois quem escuta o evento já é um 
bean CDI. Essa limitação no entando é facilmente contornada utilizando o módulo 
JSF da já citada extensão DeltaSpike. 


Mas como podemos, sem a necessidade de qualquer extensão disparar um 





evento CDI equivalente aum PhaseEvent do JSF? A implementação não é difícil, 
e usaremos os mesmos mecanismos de eventos que já vimos até aqui. Para avançar- 
mos aos poucos, vamos iniciar apenas com a implementação que resolve exatamente 
o cenário que queremos observar, que é o momento logo após o término da fase Res- 
tore View. 
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public class EventPhaseListener implements PhaseListener ( 


OInject 
OAfter ORestoreView 
private Event<PhaseEvent> afterRestoreView; 


OOverride 
public void afterPhase (PhaseEvent event) 1 
afterRestoreView.fire(event); 


QOverride 
public void beforePhase (PhaseEvent event) { 


} 


@Override 
public PhaseId getPhaseId() { 
return PhaseId.RESTORE_VIEW; 


Somente isso é suficiente para resolver nosso problema. Contudo, olhando o 
exemplo, vemos que usamos injeção de dependências dentro do PhaseListener, 
e caso você precise fazer isso dentro de uma aplicação que não utilize a versão 2.2 do 
JSF, você terá que lançar esses eventos de outra maneira. 

Para isso precisaremos do objeto BeanManager, que pode ser obtido via 
injeção (que não está disponível no nosso cenário), ou via lookup com base 
em seu nome JNDI. A obtenção dessa instância será feita através do método 
CdiUtils.getBeanManager (), que por enquanto irá abstrair as diferenças desse 
processo quando estamos em ambiente Java EE ou não. Não se preocupe, pois vere- 
mos esses detalhes quando abordarmos como usar CDI em diferentes ambientes, no 
capítulo 10. 


public class EventPhaseListener implements PhaseListener ( 
QOverride 
public void afterPhase (PhaseEvent event) { 


BeanManager beanManager = new CdiUtils().getBeanManager(); 


beanManager. fireEvent (event, new AnnotationLiteral<After> 05, 
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new AnnotationLiteral<RestoreView>()1)); 


Agora nosso código funciona em ambientes pré JSF 2.2, e apesar de mais traba- 
lhoso, o processo para enviar o evento se baseia em algo que já vimos na seção 7.4, que 





são os literais de qualificadores. Para usar o método BeanManager.fireEvent 
basta passarmos o objeto que representa o evento, e seus qualificadores, que in- 
dependente de termos ou não usado injeção de dependência, são o After e o 
RestoreVieuw. 


Como já sabemos lançar eventos dentro do PhaseListener em qualquer ver- 





são do JSF, voltaremos a incrementar a EventPhaseListener para que agora ela 
dispare para o contexto CDI evento referentes a todas as fases do JSF. Como esse livro 
é baseado em Java EE 7, usaremos o exemplo do JSF 2.2 ou superior, que suporta in- 
jeção de dependências no PhaseListener, mas com o que vimos seremos capazes 
de adaptar o exemplo para outros cenários. 

Quando estudamos sobre eventos, e também agora quando vimos como usar 
uma versão mais antiga de JSF, usamos AnnotationLiterals para diminuir a 
quantidade de injeções que precisamos usar para implementar nossa solução. Em 
vez de usarmos algo parecido com o primeiro exemplo a seguir, faremos algo mais 
parecido com o segundo. 


OInject 
OBefore ORestoreView 
private Event<PhaseEvent> beforeRestoreView; 


OInject 
@After ORestoreView 
private Event<PhaseEvent> afterRestoreView; 


OInject 
CBefore CApplyRequestValues 
private Event<PhaseEvent> beforeApplyRequestValues; 


Seguindo essa linha, teríamos pelo menos 12 (doze) pontos de injeção na nossa 
classe, pois teríamos o before e o after para cada uma das 6 (seis) fases do JSF. No lugar 
dessa abordagem, utilizaremos a forma programática como podemos ver a seguir. 
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public class EventPhaseListener implements PhaseListener ( 
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OInject 
private Event<PhaseEvent> event; 


OOverride 
public PhaseId getPhaseld() { 
return Phaseld.ANY PHASE; 


OOverride 
public void afterPhase (PhaseEvent event) { 
disparaEvento (event, new AnnotationLiteral<After>()()J); 


OOverride 
public void beforePhase (PhaseEvent event) { 
disparaEvento (event, new AnnotationLiteral<Before>0(J); 


public void disparaEvento(PhaseEvent phaseEvent, 
Annotation qualificadorAntesOuDepois)( 
Annotation qualificadorFase = null; 


if (RESTORE VIEW.equals (phaseEvent .getPhaseId())){ 
qualificadorFase = new AnnotationLiteral<RestoreView> Ot); 


} 
else if(APPLY_REQUEST_VALUES .equals (phaseEvent .getPhaseId())){ 
qualificadorFase = 
new AnnotationLiteral<ApplyRequestValues>(){}; 
J 
else if(PROCESS VALIDATIONS.equals (phaseEvent.getPhaseId())){ 
qualificadorFase = 
new AnnotationLiteral<ProcessValidations>(0) (>; 
J 
else if(UPDATE MODEL VALUES. equals (phaseEvent.getPhaseId())){ 
qualificadorFase = 
new AnnotationLiteral<UpdateModelValues>(){}; 
} 


else if(INVOKE APPLICATION.equals (phaseEvent .getPhaseId())){ 
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qualificadorFase = 
new AnnotationLiteral<InvokeApplication>() 1); 
} 
else if (RENDER RESPONSE. equals (phaseEvent .getPhaseId())){ 
qualificadorFase = 
new AnnotationLiteral<RenderResponse> () (J; 
} 


event .select (qualificadorAntes0uDepois) 
.select (qualificadorFase) 
.fire(phaseEvent); 


Ficou um trecho de código um pouco longo, mas apesar de não ser muito es- 
tético, com muitos if else, é simples de entender. Primeiramente alteramos o 
retorno do método getPhaseId() para informar que nosso listener escuta todas 
as fases do JSF. Depois apenas repetimos algo que já vimos quando estudamos even- 
tos: injetamos um evento genérico, sem qualificadores, e depois utilizamos o mé- 
todo select (Annotation qualificador) para adicionar os qualificadores no 
nosso evento antes de dispará-lo. Perceba como a interface fluente facilita nosso tra- 
balho — basta chamar duas vezes o método, sem precisar criar um array ou lista para 
passar os qualificadores de uma vez. 

É possível explorar ainda muito mais possibilidades de integração entre CDI, JSF 
e JPA, mas o intuito dessas sessões foi mostrar o caminho, e deixar que que seus co- 
nhecimentos de CDI adquiridos até aqui sugiram outros cenários. Além do mais, se 
entrarmos em muitos detalhes de JSF e JPA, desviaremos o foco do livro, que é CDI. 
Mas caso também queira aprofundar seus conhecimentos nessas duas ferramentas, 


dê uma olhada no meu livro da Casa do Código sobre esse assunto [?]. 


8.3 RELAÇÃO ENTRE CDI E JMS 


No Java EE 7, a especificação de JMS — serviço de mensageria Java — ganhou uma 
nova API, bem mais fácil de usar, e bem integrada com CDI. Nessa seção iremos ver 
como utilizar essa poderosa ferramenta junto com a funcionalidade de eventos da 
CDI. 


A nova API de JMS, que veio na versão 2.0 da especificação, trouxe para ela a 
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facilidade que os Session Beans passaram a ter a partir da sua versão 3.0. Isso por 
si já pode ser um fator que ajude a aumentar a utilização de mensageria dentro das 
aplicações Java corporativas. É verdade que somente o uso de métodos de negócio 
assíncronos já facilita bastante nosso trabalho em execuções mais custosas, mas JMS 
vai além. 

O serviço de mensageria Java dá a nossa aplicação uma capacidade de processa- 
mento assíncrono muito grande. Para exemplificar, vamos imaginar uma aplicação 
de processamento de pagamentos de uma outra aplicação de comércio eletrônico. 
Apesar das interfaces da atualidade nos dar a impressão de ser tudo síncrono, vamos 
pensar mais especificamente em boletos, que naturalmente são assíncronos, geral- 
mente sendo processados com um dia de atraso. 

Imagine que sua aplicação tem um alto poder de processamento, porém devido a 
uma super promoção de um grande site de vendas, as requisições começaram a che- 
gar em um volume muito maior do que sua aplicação consegue processar. O cenário 
poderia ser catastrófico, sua aplicação poderia parar de receber requisições enquanto 
tenta processar a demanda, e o site de vendas poderia perder inúmeros negócios pois 
não conseguiria terminar a venda, que depende do sistema de pagamentos. Depen- 
dendo do caso, caberia até processo. 

O JMS, assim como qualquer outro serviço, não é a Panaceia que deixará tudo em 
ordem em um piscar de olhos, mas ajudará e muito. No nosso exemplo hipotético, 
a aplicação de vendas, não solicitaria para nossa aplicação processar o pagamento e 
ficaria esperando. Ela registraria a venda na fila de processamento e responderia que 
em instantes o usuário receberia a notificação ou então faria uma tela de progresso 
que faz o usuário aguardar alguns instantes para dar a impressão que o processo é 
“online” 

Essa fila geralmente é persistente, ou seja, se tivermos mil vendas para serem pro- 
cessadas e o servidor cair, quando este voltar ainda teremos os mil itens na fila. Além 
disso, a fila é gerenciada automaticamente pelo servidor de aplicação. Enquanto exis- 
tirem elementos na fila, o bean responsável por processar as vendas será chamado. 
E o que dá poder a essa ferramenta é que há, na verdade, um pool de beans de um 
mesmo tipo, paralelizando o processamento o máximo possível para sua aplicação 
dar conta da demanda. Esses beans que processam elementos de uma fila, ou tópico, 
são os MDBs, ou Message-Driven Beans. 

A principal diferença de um Message-Driven Bean para um Session Bean é que a 
aplicação de vendas não acessa diretamente o MDB como faria com o EJB. Ela co- 
loca a solicitação na fila, e o container é que chama o MDB para processar o próximo 


164 


Casa do Código Capítulo 8. A relação da CDI com as demais especificações Java EE 





elemento da fila. Assim como os EJBs Stateless os MDBs também não mantém es- 
tado, e por isso em ambos temos o uso do pool, que é um dos responsáveis pela boa 
responsividade. 

Esse livro, porém, não tem como finalidade mostrar como utilizar JMS para au- 
mentar a escalabilidade das nossas aplicações, por hora veremos como criar uma 
ponte entre os eventos CDI e as mensagens JMS. 

Umas das principais diferenças entre os eventos CDI e as mensagens JMS é que 
os eventos só existem dentro do contexto de uma aplicação, enquanto as mensagens 
podem ser consumidas por diversas aplicações. Isso porque a o tópico ou a fila não 
são privativos de uma aplicação, são recursos que ficam disponíveis para qualquer 
aplicação que conseguir se comunicar com o servidor onde elas estão. Em cenários 
maiores teremos inclusive servidores dedicados exclusivamente a processar filas e 
tópicos. 

Nessa seção, usaremos a facilidade dos eventos e a disponibilidade das mensa- 
gens para fazer com que o evento lançado por uma aplicação seja escutado por outra. 


Comunicando duas aplicações com uma ponte CDI - JMS 


Dentro de um mesmo sistema podemos utilizar eventos para integrar módulos 
diferentes com um baixo acoplamento, mas quando pensamos em aplicações dife- 
rentes temos ainda mais opções. Por exemplo, é possível, ao cadastrar um novo fun- 
cionário, disparar em outros sistemas a tarefa de criação de conta no controlador de 
domínio e liberar seu acesso na cancela do estacionamento. E no momento do desli- 
gamento do funcionário cancelar todos os acessos anteriormente concedidos. Pode 
até ser possível ter todos esses controles no mesmo sistema, mas o mais comum não 
é esse. 

No exemplo que vamos analisar agora, vamos considerar a integração com uma 
agência de empregos. Quando um funcionário se desligar da empresa, e não for 
por aposentadoria, nós notificaremos a agência para que ela já inicie a busca pela 
recolocação do profissional no mercado de trabalho. Como nossa aplicação só está 
tratando aposentadoria e demissão, vamos fazer em cima do exemplo de demissão, 





mas seria possível olhar qualquer evento de desligamento e usar o EventMetadata 
para ignorarmos os desligamentos que tivessem qualificador de aposentadoria. 


Conceitualmente, o que desejamos é algo assim. 
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Notificador 


Observador 1 Observador 2 Observador 3 Observador 4 





Contexto aplicação A Contexto aplicação B 


Figura 8.1: Evento da aplicação A sendo consumido pela aplicação B via JMS 


Pela imagem vemos um evento produzido na aplicação A, sendo consumido por 
4 (quatro) observadores, dois deles da aplicação B. Via código o esperado seria um 
código semelhante ao seguinte. 


public class GerenciadorFuncionarioBean { 


OInject QDesligamento (DEMISSAO) 
private Event<Funcionario> eventoDemissao; 


public void demitirFuncionario(Funcionario funcionario)( 
eventoDemissao.fire(funcionario); 


E o seguinte código já no sistema da agência de empregos: 


public class AgenciaDeEmpregos { 
public void ajudarFuncionarioDemitido( 
OUbserves QDesligamento (DEMISSAO) Funcionario funcionario, 


Logger logger)( 


logger.info("Ajudando {} a conseguir um novo emprego", 
funcionario); 
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Para que isso funcione, no entanto, vamos precisar colocar na nossa aplicação um 
observador que escute esse evento e cria uma mensagem na fila JMS, e na aplicação 
da agência de empregos colocar um MDB que leia a mensagem e crie novamente o 
evento nos mesmos moldes do original. Para simplificar, criaremos nossa integração 
de forma específica para esse cenário, mas com um pouco de abstração e reflexão é 
possível criar implementações genéricas que atendem bem a maioria dos casos. 

Iniciaremos pelo código que cria a mensagem JMS. Nosso exemplo será baseado 
na API simplificada do JMS 2.0, mas é possível portar o código para a API tradicional 
caso esteja executando em ambiente pré Java EE 7. 


OStateless 
public class ObservadorDeFuncionarios { 


OInject 
private JMSContext jmsContext; 


OResource (mappedName = "jms/demissaoTopic") 
private Topic topicoDemissao; 


CAsynchronous 

public void notificaAgenciaDeEmprego( 
@Observes ODesligamento (DEMISSAO) Funcionario funcionario, 
Logger logger) throws Exception 


logger.info("Enviando o(a) {} para agencia de empregos", 


funcionario); 
jmsContext.createProducer() .send(topicoDemissao, funcionario); 


Estamos usando um tópico JMS que está no mesmo servidor que nossa 





aplicação, e recuperamos esse tópico via GResource (mappedName = 
"jms/demissaoTopic"). Tópicos e filas devem ser criados no servidor de 
aplicação que estivermos utilizando, não é algo da aplicação. No glassfish, só 
precisamos tomar o cuidado de não dar o mesmo nome JNDI e nome físico para 
o tópico ou fila, senão o nome não será encontrado. O valor que passamos para o 
atributo mappedName da anotação EResource é o nome JNDI, e não o físico. 
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Perceba que fizemos nosso observador ser assíncrono, pois assim, caso passemos 
a utilizar um servidor JMS remoto, uma possível degradação no tempo de resposta 
ao colocar a mensagem na fila não impactará no método de negócio. 

A implementação como um todo ficou bem simples. Usamos o JMSContext 
para criar um producer de mensagens e em seguida enviamos o objeto funcionário, 
que deve ser serializável, para o tópico de demissões. Agora no lado da agência de 
empregos teremos um MDB que escuta esse tópico e recria a mensagem no contexto 
daquela aplicação. 


OMessageDriven(mappedName = "jms/demissaoTopic") 
public class AgenciaDeEmpregosMessageBean implements MessageListener { 


OInject CDemissao 
private Event<Funcionario> eventoDemissao; 


OInject 
private Logger logger; 


@Override 
public void onMessage (Message message) { 
try ( 
Funcionario funcionario = 


message.getBody (Funcionario.class); 


logger.info("Recebida a demissão do funcionario {} via JMS", 
funcionario); 


eventoDemissao.fire(funcionario); 


} catch (JMSException ex) { 


logger.error("Erro ao ler a mensagem via JMS", ex); 








} 
} 
} 
Um MDB, como acabamos de ver, é simplesmente um bean ano- 
tado com @javax.ejb.MessageDriven e que implementa a in- 
terface javax. jms.MessageListener. No corpo do método 


onMessage (javax.jms.Message) precisamos apenas recuperar o con- 
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teúdo da mensagem, que nesse caso é um objeto do tipo Funcionario. Para isso, 
utilizamos o método get Body que foi adicionado à versão 2.0 de JMS para facilitar 
o trabalho. Com o funcionário em mãos, e sabendo que essa mensagem é referente 
a uma demissão, basta lançar um novo evento CDI. 


Para abstrairmos essa funcionalidade, poderíamos criar um observador global 





do lado da nossa aplicação, e via EventMetadata criar um objeto que represente o 
evento. Em vez de termos o objeto funcionário, teríamos também os qualificadores 
utilizados. Na outra aplicação, no exemplo a agência de empregos, leríamos esse ob- 
jeto que representa o evento e, antes de lançá-lo no contexto CDI, especificaríamos 
os qualificadores de forma programática como já fizemos algumas vezes. Além des- 
sas alterações, criaríamos também um tópico com título mais genérico, como por 





exemplo "jms/cdiEventsTopic" ou algo parecido. 


Perceba também que para diferenciar mais uma aplicação da outra, utilizamos o 





qualificador EDesligamento (DEMISSAO), e na agência de empregos utilizamos 
GDemissao. Para facilitar a criação de algo genérico, que possa ser compartilhado 
pelas diversas aplicações da nossa organização, o melhor é criarmos um jar com o 
conjunto de qualificadores e classes que serão compartilhadas entre as aplicações. 
Geralmente esses jars não possuem qualquer classe inteligente, apenas tipos com- 





partilhados, e são chamados de <nomeDaAplicacaoDeOrigem>-client. jar. 
Obviamente essa é apenas uma sugestão, mas fica simples perceber que to- 
das as aplicações que precisarão se comunicar com a nossaApp precisão do 


nossaApp-client. jar. 


8.4 EMPACOTANDO AS MELHORIAS 


Todos os exemplos que vimos nesse capítulo são passíveis de empacotamento, ou 
seja, podemos colocar essas pequenas melhorias em um projeto separado, gerar um 
jar, e colocar nas nossas aplicações. Qualquer aplicação que utilizar esse jar terá auto- 
maticamente suporte à injeção de recursos da JPA e JSF, e fazendo as generalizações 
comentadas na última seção, poderíamos ter eventos CDI passando de uma aplica- 
ção para a outra via JMS. 

Implementar isso não é nada complicado — basta colocar os arquivos 
de configuração no local correto. Enquanto nas aplicações web os arquivos 





faces-config.xml e beans.xml ficam geralmente na pasta WEB-INF, ao criar 





uma biblioteca precisamos colocar esses arquivos dentro da pasta META-INF que 
fica na raiz do jar. 
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Assim, mesmo ainda sem termos visto o mecanismo de extensões propriamente 
dito, já conseguiremos criar bibliotecas de apoio com muita funcionalidade interes- 
sante. 


170 


CAPÍTULO 9 


Extensões CDI 


Uma especificação nada mais é do que uma padronização de como fazer determi- 
nada tarefa. A JPA padroniza o mapeamento objeto-relacional, JSF padroniza como 
desenvolver clientes web com um sofisticado gerenciamento de estado e com CDI 
temos a padronização de como injetar dependências e gerenciar escopos dentro do 
Java EE. Porém, sempre que algo é padronizado, a tendência é limitar a inovação. 
Como, por exemplo, inovar no mapeamento objeto-relacional se a JPA define as fun- 
cionalidades? 

A forma encontrada para que a inovação continue apesar das especificações é 
através da adição de funcionalidades não especificadas. Estas adicionam funcionali- 
dades importantes às implementações das especificações. O exemplo mais notório é 
o da JPA, onde temos o EclipseLink (http://www.eclipse.org/eclipselink) como im- 
plementação de referência, e o Hibernate (http://hibernate.org) como a implemen- 
tação mais utilizada. 

Prosseguindo na análise da JPA, temos funcionalidades não especificadas nessas, 
e em outras implementações, que adicionam características muito importantes em 
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cada implementação. No Hibernate temos o cache de consulta, que nos permite evi- 
tar diversas consultas desnecessárias no banco de dados, além do cache de segundo 
nível de entidades que foi adicionado à especificação depois que já estava disponí- 
vel no Hibernate. Já no EclipseLink temos o suporte a multitenant, que nos permite 
escolher diferentes estratégias para fazer nossa aplicação funcionar com diferentes 
clientes. Isso permite que uma mesma instância de aplicação de vendas seja utili- 
zada por diferentes sites de e-commerce, por exemplo. 

Qual o problema de uma implementação adicionar funcionalidades não espe- 
cificadas? Praticamente nenhum, desde que você não troque de implementação. O 
“detalhe” é que a possibilidade de trocar de implementação é uma das vantagens da 
especificação, e acabamos perdendo isso. Se por exemplo utilizarmos o suporte a ca- 
che de consulta do Hibernate, caso mudemos para o EclipseLink teremos que fazer 
alguma alteração na nossa aplicação para usar o suporte equivalente do EclipseLink. 
Há casos também em que uma implementação não tem um equivalente à funcio- 
nalidade da outra. Por exemplo, até o momento o Hibernate não tem um suporte a 
multitenant tão elaborado quanto o do EclipseLink. 


Qual a diferença do suporte a extensões da CDI? 


Como a CDI é uma especificação mais recente, inteligentemente adicionou o 
suporte a extensões portáveis, de forma que implementadores da especificação, ou 
mesmo qualquer um de nós, pudessem desenvolver funcionalidades além das espe- 
cificadas que não dependam de uma implementação, e sim da própria especificação. 

Voltando ao paralelo com a JPA, seria como se pudéssemos adicionar a funcio- 
nalidade de multitenant do EclipseLink enquanto usamos o Hibernate como imple- 
mentação da JPA. Isso nos permite ao mesmo tempo desfrutar da inovação constante 
que as implementações das especificações nos oferece, sem, no entanto, ficarmos 
presos a essas implementações. Usamos a implementação e as funcionalidades adi- 
cionais, mas na hora de trocar de implementação, continuamos com os adicionais. 
Essa sofisticação foi resultado da evolução do framework Seam, desenvolvido pela 
JBoss, e que acabou servindo de base para a CDI. 


9.1 Do SEAM À CDI 


O JBoss Seam foi um framework criado com o objetivo de aparar as arestas existen- 
tes entre as diversas especificações do Java EE 5. Essa versão do Java EE foi focada na 
facilidade de implementação, e foi um divisor de águas do Java para aplicações cor- 
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porativas, pois saiu de algo extremamente verboso, cheio de XML, para algo simples 
de implementar utilizando as anotações, que haviam sido introduzidas pouco antes 
no Java 5. 

A utilização do Java FE ficou bem mais simples, com JPA 1.0, JSF 1.2 e EJB 3.0. 
Porém, essas especificações não tinham um trabalho de integração muito elaborado, 
e aí entrava o Seam, que podemos traduzir para junção, integração. 

O Seam fez bastante sucesso, e além de simplesmente integrar as diversas es- 
pecificações do Java EE, passou a oferecer uma coleção de utilidades, como gera- 
ção facilitada de PDFs, segurança, integração com BPM (workflow) e engine de re- 
gras (Drools), dentre outras. Enquanto algumas dessas utilidades são integrações 
com outros frameworks, que podem ser utilizados separadamente, como o Drools 
(http://www.jboss.org/drools) e o jBMP (http://www.jboss.org/jbpm), outras coisas 
como o suporte a escrita de PDFs através de tags, como se fosse um HTML, era algo 
totalmente integrado ao Seam. 

Ocorre que, conceitualmente, muitas dessas utilidades eram acessórias, e seria 
interessante poder utilizá-las com qualquer framework. Enquanto isso, o Seam pos- 
suía um núcleo que era o responsável pela injeção de dependências; núcleo este 
que “concorria” com o núcleo de outros frameworks como o Spring (http://www. 
springsource.org/spring-framework). 

Como o Java EE não possuía uma especificação que padronizasse esse meca- 
nismo, em vez de desenvolver uma nova versão do Seam evoluindo tanto o core 
quanto os utilitários, a JBoss liderou a especificação da CDI como substituta do nú- 
cleo do Seam. E como era desejável que os utilitários do Seam não se perdessem, 
mas também adicionar tudo aquilo na especificação desviaria seu foco, a solução foi 
tratá-los como extensões. Dessa forma, a CDI já nasceu com a ideia de ser extensí- 
vel. A seguir é possível ver uma imagem, que ficava disponível no site do Seam, que 
ilustra essa evolução do Seam 2, para o Seam 3, que passou a ser apenas uma coleção 
de extensões. 
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Mail 
International 
Remoting 
Persistence 
JMS 


JSR-299 Contexts and Dependency 
Injection (CDI) Container (such as Weld) 


Configuration Configuration 
Contexts Contexts 
Dependency Injection Dependency Injection 
Events Events 

Initialization Initialization 
Interceptors Interceptors 





Figura 9.1: Evolução do Seam 2 até a CDI e o Seam 3 


A JBoss no entanto descontinuou o Seam 3, e passou o projeto para a Fundação 
Apache, que o chamou de DeltaSpike (http://deltaspike.apache.org) . Alguns mó- 
dulos, entretanto, tornaram-se bibliotecas independentes, como pode ser visto na 
página do Seam (http://www.seamframework.org) . 


9.2 EXTENSÕES PORTÁVEIS DISPONÍVEIS 


O projeto DeltaSpike ainda está bem recente, e apesar de ter se baseado em versões 
completas dos módulos do Seam 3, ainda não tem uma versão estável disponível. 
Ainda é possível acessar os módulos do Seam 3, mas eles não são mais atualizados, 
então bugs não serão corrigidos nem novas funcionalidades introduzidas. Mesmo 
assim pode ser uma opção caso o DeltaSpike não ofereça a funcionalidade que pro- 
curamos. 

Há ainda o MyFaces CODI (https://bitly.com/myfaces-codi) , também da apa- 
che, que tem diversas funcionalidades mais voltadas para JSF, como podemos ver 
na wiki do projeto (https://bitly.com/codi-wiki) . Umas das principais vantagens do 
CODI, são os diferentes escopos oferecidos, como uma conversação diferente da pa- 
drão do CDI, com suporte a restart, subconversações, grupo de conversações dentre 
outras peculiaridades. Temos também escopos window e view access. A documen- 
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tação dessas funcionalidades está disponível na wiki do projeto CODI, no módulo 
JSF. Certamente esta é uma página que vale a pena ser visitada. 

Há também esta lista com diversas extensões CDI: https://groups.diigo.com/ 
group/cdi-extensions. Aqui é possível encontrar link para as extensões do Seam 3, 
que já não estão mais listadas na página do projeto, além de outros que apontam 
para posts de blogs e repositórios (github ou outros) que possuem as mais diversas 
implementações de extensões CDI. 

Mas o que podemos esperar dessas extensões? Além de algumas inovações, o 
mais comum é trazer para o ambiente não Java EE, funcionalidades que geralmente 
já estão disponíveis nesse ambiente. Nesse caso não temos algo novo, apenas conse- 
guimos, por exemplo, desfrutar de gerenciamento automático de transações dentro 
de um servlet container como Tomcat ou Jetty. 

Temos também, no exemplo do JSF, um adiantamento de funcionalidades que 
viriam somente em versões seguintes das especificações. Por exemplo, a maioria das 
extensões integradas com JSF permitem a injeção de dependências dentro de con- 
versores, validadores e PhaseListeners em versões anteriores ao JSF 2.2, quando 
isso ainda não era possível nativamente. 


9.3 CRIANDO NOSSAS EXTENSÕES 


Criar uma extensão CDI é simples, e faremos dois exemplos que provarão isso. An- 
tes vamos entender o que é preciso para criar uma extensão. A CDI faz uso de uma 
funcionalidade adicionada no Java 6, que é uma forma simplificada, e padronizada, 
de carregar a implementação de um serviço qualquer. É bem parecido com o que vi- 
mos lá no início, na seção 1.3, onde carregávamos a implementação de uma interface 
de um arquivo properties. 

Essa funcionalidade é oferecida através da classe 
java.util.ServiceLoader, e seu funcionamento é simples, basta criarmos um 
arquivo texto com o nome da interface (ou classe abstrata) que estamos implemen- 





tando, e colocá-lo dentro da pasta META-INF / services. No nosso caso, estaremos 








implementando a interface javax.enterprise.inject.spi.Extension, 
então todas as extensões CDI estarão no arquivo 








META-INF/services/javax.enterprise.inject.spi.Extension. 





Dentro desse arquivo criaremos uma linha com o nome completo de cada classe 


que implementa a interface em questão. 





A interface Extension da CDI não possui qualquer método para implemen- 
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tarmos, é apenas o que chamamos de interface de marcação. Em vez de usarmos 
método fixos, a CDI definiu diversos eventos que podemos observar durante a su- 
bida da aplicação, e então fazer as modificações que desejarmos. Existem diversos 
eventos que podemos observar, tais como: 


e BeforeBeanDiscovery 

e AfterBeanDiscovery 

e ProcessAnnotated Type 
e ProcessBeanAttributes 
e ProcessProducer 

e ProcessObserverMethod 


e ProcessInjectionPoint 


Além desses, temos muitos outros que podem ser encontrados no pacote 





javax.enterprise. inject.spi. Aliás, agora que estaremos desenvolvendo ex- 
tensões, passaremos a olhar bastante para os pacotes spi que existem dentro da CDI. 
SPI significa Service Provider Interface, e como a partir de agora estaremos desenvol- 
vendo extensões que proveem serviços dentro da CDI, é essa interface que usaremos. 
Interface aqui no sentido mais amplo, como um ponto de vista da API de CDI. 

O funcionamento básico das extensões é observar determinado evento, e modi- 
ficar o objeto detectado pela CDI. Como o mecanismo de extensão é projetado para 
nos permitir alterar o contexto original, nossas extensões executam logo na subida 
da aplicação, antes da injeção de dependência estar disponível, e temos acesso a obje- 
tos modificáveis que representam o contento até então. Ou seja, podemos modificar 
as anotações de um bean que acabou de ser lido, ou mesmo acessar a listagem dos 
beans e remover, ou adicionar, um elemento lá dentro do contexto. 

Por mais que este mecanismo de extensão seja muito bem projetado, e simples 
de usar, ainda existem detalhes que não estão disponíveis na SPI, nos obrigando a 
utilizar classes específicas da implementação, que no nosso caso é a implementação 
de referência, o Weld. Quando precisamos utilizar desses mecanismos, temos as 
chamadas extensões não portáveis, pois estamos nos prendendo à implementação. 
Isso muitas vezes não é um problema, até porque já é comum nos prender a uma im- 
plementação quando usamos JPA, por exemplo. Mas como extensões portáveis são 
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uma evolução, a tendência é esse mecanismos continuar evoluindo para precisarmos 
cada vez menos desenvolver extensões não portáveis. 

Nos exemplos que iremos desenvolver, veremos uma extensão portável, que pode 
ser integrada em um projeto que usa por exemplo OpenWebBeans (implementação 
de CDI da Apache); e outra não portável, que faz uso de classes do Weld. Por sorte, 
os dois principais servidores de aplicação open-source, JBoss/Wildfly e Glassfish, 
utilizam o Weld como implementação. 


9.4 EXTENSÃO PORTÁVEL: USANDO CONVENÇÃO EM VEZ DE 
CONFIGURAÇÃO 


Provavelmente você conhece um conceito muito utilizado hoje em dia que é a uti- 
lização de convenção em vez de configuração. Sabemos que configurar algo com 
anotação é bem simples, ainda mais quando temos estereótipos que podem combi- 
nar diversas configurações em uma única anotação. 

Mesmo tendo meios bem simples de configurar, vamos criar uma convenção: 
qualquer classe dentro de um pacote controllers ou que tenha nome terminado 
em Controller deve receber o estereótipo &Controller. Esse estereótipo ape- 
nas define o escopo request e adiciona um nome ao bean. Na prática é igual ao es- 
tereótipo eModel que já vem na CDI, mas como já vimos na seção 7.1, podemos 
usar nosso estereótipo próprio para adicionar interceptadores e até mesmo outros 
estereótipos. Por esse motivo vamos usar essa anotação, em vez de separadamente 


adicionar ENamede ERequestScoped ao nosso bean. Então vamos ao exemplo. 


public class ControllerPorConvensaoExtension implements Extension { 


private Logger logger = LoggerFactory 
. getLogger (ControllerPorConvensaoExtension.class); 


void configuraControllers(O0bserves ProcessAnnotatedType pat) { 
AnnotatedType at = pat.getAnnotatedType(); 


logger. info("Passando pelo AnnotatedType {}", at) 


A estrutura da extensão é somente essa, bem simples. Estamos utilizando 


o evento ProcessAnnotatedType, que observa cada AnnotatedType, 
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que representa cada objeto dentro do contexto CDI. Temos também o 
evento ProcessBeanAttributes, que observa cada BeanAttributes, 
que é uma outra visão, ainda mais simples, de cada AnnotatedType. 
Agora para que nossa extensão possa ser carregada, precisamos do arquivo 








META-INF/services/javax.enterprise.inject.spi.Extension como 





já foi dito. Dentro desse arquivo temos apenas o nome da classe da nossa extensão. 


br.com.casadocodigo.livrocdi.extension.ControllerPorConvensaoExtension 


Vista a estrutura, vamos implementar o conteúdo do método 


configuraControllers. 


void configuraControllers(O0bserves ProcessAnnotatedType pat) { 


AnnotatedType at = pat.getAnnotatedType(); 
Class classe = at.getJavallass(); 


if (classe.getPackage() .getName() .endsWith("controllers") 
|| classe.getSimpleName() .endsWith("Controller")) 1 


pat.setAnnotatedType (new AnnotatedTypeControllerWrapper (at)); 
logger. info("Controlador encontrado: {}", classe); 


Acabamos de implementar a lógica da nossa convenção: pacote 
controllers ou classe com nome terminado em Controller. O traba- 
lho de adicionar o estereótipo Controller vai ser feito dentro da classe 
AnnotatedTypeControllerWrapper, mas antes disso, vamos analisar onde ela 
está sendo usada. 

A grande facilidade do mecanismo de extensão da CDI é que cada evento obser- 
vado, como o ProcessAnnotatedType nos devolve um objeto relacionado. Nesse 
caso estamos executando um código nosso a cada AnnotatedType descoberto pelo 
contexto. Esse objeto pode ser recuperado pelo método getAnnotatedType, mas 
pode ser alterado pelo método setAnnotatedType. Para todos os outros even- 
tos que podemos observar para construir nossas extensões o funcionamento é muito 
parecido. Recuperamos o objeto recém analisado através do método get, e pode- 
mos usar o método set para trocar esse objeto por outro com as características que 
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desejamos. Outro método que geralmente está disponível nos objetos ProcessxYZ 
é o veto (), que pode ser utilizado para remover esse objeto do contexto, como se 
ele estivesse anotado com @Vetoed. 

O código da classe AnnotatedTypeControllerWrapper tem um funciona- 
mento muito simples, como podemos ver a seguir. 


class AnnotatedTypeControllerWrapper implements AnnotatedType ( 
private AnnotatedType wrapped; 


AnnotatedTypeControllerhrapper (AnnotatedType original) { 
this.wrapped = original; 


OOverride 
public Set<Annotation> getAnnotations() { 
Set<Annotation> annotations = 
new HashSet<>(wrapped.getAnnotations()); 
annotations.add(new AnnotationLiteral<Controller>()1)); 
return annotations; 


@Override 
public Class getJavaClass() { 
return wrapped.getJavaClass(); 


Existem vários outros métodos que precisam ser implementados, mas todos 
seguem a mesma filosofia do getJavaClass (), apenas repassando a invoca- 
ção para o objeto wrapped. Agora analisemos o método que nos interessa: 
getAnnotations (). Vejamos como ele é simples, consistindo apenas em adici- 
onar a anotação Controller na lista de anotações da nossa classe. Assim, não 
fazemos as demais anotações pararem de funcionar, apenas adicionamos um este- 
reótipo. Se a classe já tiver um escopo ou um nome, os dados do nosso estereótipo 
será sobrescrito por essas anotações específicas. Bem simples e funcional. 
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9.5 EXTENSÃO NÃO PORTÁVEL: EVENTOS ASSÍNCRONOS 
FORA DO JAVA EE 


Apesar de muito simples de usar, o mecanismo de extensão não nos deixa manipu- 
lar todos os objetos que gostaríamos. Nesse exemplo vamos manipular os métodos 
observadores, queremos trocar o observador normal por um que execute em uma 
Thread separada para permitir a execução assíncrona. 

Na CDI podemos acompanhar os métodos observadores presentes na aplicação 
da seguinte forma. 


public class EventoAssincronoExtension implements Extension { 


private Logger logger = LoggerFactory 
. getLogger (EventoAssincronoExtension.class); 


public void analisalbservers (O0bserves Process0bserverMethod pom) 
ObserverMethod observerMethod = pom.getObserverMethod() ; 


jogger.info("Método {} é um observer" + observerMethod) ; 





Como vimos ao construir a extensão ControllerPorConvensaoExtension, 
o comum é termos um método get e um set em cada ProcessxyZ dentro 





da SPI da CDI. Porém a interface ProcessObserverMethod não possui um 
método setObserverMethod, nos obrigando a utilizar classes específicas do 
Weld, deixando de ter uma extensão portável. Em versões futuras podemos ter essa 
limitação removida; por hora veremos como sair dessa situação, e de situações que 
podem ocorrer no nosso dia a dia e que a SPI não nos ofereça uma saída. 


A primeira coisa que faremos é observar se a classe que implementa a inter- 





face ProcessObserverMethod nos oferece esse método. A classe em questão 





éa org. jboss.weld.bootstrap.events.ProcessObserverMethodImpl1, 
mas ela também não oferece um setObserverMethod. A saída será utilizar um 
evento diferente, o AfterBeanDiscovery. 

Esse evento é lançado depois que todos os beans, e também os observadores 
foram descobertos e não há problema em suas definições. Então depois de tudo 
pronto, vamos tentar mudar algo que não tivemos abertura para mudar no momento 
apropriado. A estrutura da nossa extensão ficará então da seguinte forma. 
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public class EventoAssincronoExtension implements Extension { 


private Logger logger = LoggerFactory 
. getLogger (EventoAssincronoExtension.class); 


void afterBeanDiscovery (OUbserves AfterBeanDiscovery abd, 


BeanManager bm) { 
logger.info("Todos os beans já foram lidos"); 


Apenas trocamos o evento que iremos observar. Nesse trecho, adicionamos 





tambémo javax.enterprise.inj ct.spi.BeanManager. Enquanto em um 
observador de eventos comum podemos receber qualquer objeto como dependên- 
cia do método, bastando para isso colocar mais parâmetros além no anotado pelo 
Gobserves; quando implementamos uma extensão, o único objeto injetável é o 
BeanManager. Isso porque o método será chamado antes do contexto estar termi- 
nado, assim não seria possível encontrar as dependências. Já o BeanManager é 
um objeto único e central na CDI, logo ele existe desde o início da inicialização da 
aplicação. 

Nesse momento, podemos utilizar os método do BeanManager para acessar 
suas estruturas internas e modificá-las. Podemos fazer isso com os beans e diversos 
outros elementos do contexto, mas infelizmente não temos uma maneira de alterar 
a definição de observadores de eventos através dessa interface. 

A saída será utilizar a implementação de BeanManager, e então recuperar a 
lista de observadores. Faremos isso da seguinte maneira. 


void afterBeanDiscovery(O0bserves AfterBeanDiscovery abd, 
BeanManager bm) { 


BeanManagerImpl manager = ((BeanManagerProxy) bm) .delegate(); 


List<DbserverMethod<?>> observers = manager .getObservers(); 


Através da classe org. jboss.weld.manager.BeanManagerImpl1 conse- 
guimos acessar o método getObservers (), e aí sim poderemos prosseguir na 
implementação da nossa extensão. Porém antes de avançar, vamos entender melhor 
como essa extensão irá funcionar. 
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Novamente os observadores assíncronos 


Já vimos sobre observadores assíncronos de eventos na seção 7.5. Naquela oca- 
sião, vimos que para usar a funcionalidade precisávamos que o bean fosse um EJB, 
e que o método estivesse anotado com GAsynchronous. Também já vimos que 
a CDI não oferece uma forma nativa de termos observadores assíncronos, pois o 
intuito não é competir com outras especificações. Logo, se quisermos executar CDI 
fora do servidor de aplicações, sem EJBs, precisaremos de uma extensão que nos ofe- 
reça isso. Podemos buscar uma pronta nas referências apresentadas neste capítulo, 
ou então desenvolver a nossa. 

O intuito da nossa implementação não é competir com qualquer extensão de- 
senvolvida por organizações como Apache ou JBoss, e sim mostrar como podemos 
implementar coisas muito úteis quando não encontrarmos uma alternativa pronta. 

No nosso exemplo, teremos apenas uma anotação Java simples, EAssincrono, 
que será colocada sobre os métodos observadores que desejamos que sejam execu- 
tados de forma assíncrona. A diferença para a anotação Asynchronous, é que a 
nossa pode ser colocada em um bean comum, e não apenas em EJBs. 

Como a SPI da CDI não prevê esse tipo de manipulação de observadores, não há 
uma forma simples de manipularmos esses métodos. Precisaremos de uma tarefa um 
pouco mais trabalhosa - mas nem tanto - e que envolve mais algumas classes espe- 
cíficas do Weld. Como estamos usando algo específico da implementação, podemos 
ter alterações dessas classes no futuro, por esse motivo o melhor é seria usarmos só 
classes da especificação. Mas já vimos que no nosso exemplo não será possível. 

Vejamos então como trocar o ObserverMethod padrão, por um wrapper que 
faça-o executar em uma Thread separada. 


void afterBeanDiscovery (O0Ubserves AfterBeanDiscovery abd, 
BeanManager bm) { 


BeanManagerImpl manager = ((BeanManagerProxy) bm) .delegate(); 

List<DbserverMethod<?>> observers = manager .getObservers(); 

for (ObserverMethod<?> observerMethod : observers) { 
ObserverMethodImpl observerMethodImpl = 


(ObserverMethodImpl) observerMethod; 


MethodInjectionPoint methodInjectionPoint = 
observerMethodImp1 .getMethod() ; 
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AnnotatedMethod annotatedMethod = 
methodInjectionPoint.getAnnotated(); 
Method method = annotatedMethod. get JavaMember () ; 


if (method. isAnnotationPresent (Assincrono.class)) { 


//aqui chegamos ao ponto que desejávamos! 


Precisamos usar diversas classes para poder chegar até o 
java.lang.reflect.Method que representa o método observador, 
para então verificar se ele está anotado com @Assincrono, através de 
if (method. isAnnotationPresent (Assincrono.class)). 

Depois de tudo isso, conseguimos identificar o ObserverMethod que deseja- 
mos trocar dentro do contexto CDI. Para isso criaremos uma classe wrapper assim 
como fizemos na extensão ControllerPorConvensaoExtension. E então rea- 





lizaremos, dentro do if anterior, a troca de um objeto pelo outro. 


if (method. isAnnotationPresent (Assincrono.class)) 1 


ObserverMethod original = observerMethodImpl; 
ObserverMethod observerMethodhrapper = 
new ObserverMethodWrapper (original); 


observers.remove (original); 
abd.add0bserverMethod (observerMethodWrapper) ; 


Após instanciarmos nossa classe ObserverMethodWrapper, re- 
movemos a original da lista de observers e adicionamos o obser- 
vador novo em seu lugar. Adicionamos o novo usando o método 
AfterBeanDiscovery.addObserverMethod (ObserverMethod). Pode- 
mos perceber que o método de adicionar o observador existe, o que não existe é 
uma forma padrão de trocar o objeto antigo pelo novo. Optamos pelo método 
porque ele faz parte da SPI, então preferimos utilizá-lo, senão adicionaríamos ele 
direto na lista observers, que é uma referência de dentro do contexto CDI. 
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Falta agora o código da classe ObserverMethodikrapper, que trocará a cha- 
mada original por uma que lança uma nova Thread. 


import java.util.concurrent.ExecutorService; 


public class ObserverMethodWrapper<T> implements ObserverMethod<T> { 


private Logger logger = LoggerFactory 
. getLogger (DbserverMethodWrapper.class); 


private ObserverMethod delegate; 
private ExecutorService executor; 


public ObserverMethodWrapper (ObserverMethod delegate) 1 
this.delegate = delegate; 


Ainda não vimos todos os métodos da nossa classe, mas a estrutura básica já nos 





fornece alguma informação. Perceba a utilização da classe ExecutorService, 
que serve para dispararmos execuções de Runnables em novas Threads. Vamos 
assumir que conseguiremos uma instância dessa interface e prosseguir. Depois vol- 
taremos e analisaremos um pouco sobre como conseguimos essa instância. 

A grande maioria dos métodos são apenas delegações de chamadas de método 
para o objeto delegate. 


@Override 

public Class getBeanClass() { 
return delegate.getBeanClass(); 

} 

@Override 

public Type getObservedType() { 
return delegate.get0ObservedType(); 

J 


//delegação dos demais métodos para o delegate 


@Override 
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public void notify(Object event) { 
getExecutor() .execute (new ExecuteEventRunnable(delegate, event)); 


O método mais interessante nesse exemplo é o notify (Object). Esse é o mé- 
todo que é responsável por disparar a notificação para o observador. O que fazemos 
aqui é, em vez de somente delegar a chamada para o objeto delegate, o que aca- 
baria não surtindo nenhuma alteração no comportamento padrão do observador, 
chamar o delegate.notify (event) dentro de uma nova Thread. 





O método getExecutor() nos devolve uma instância de 





ExecutorService, e sabendo que esse objeto consegue disparar a execução 
de um Runnable em uma nova Thread, agora precisamos ver a implementação 








da classe ExecuteEventRunnable. 


class ExecuteEventRunnable implements Runnable { 


private ObserverMethod delegate; 
private Object event; 


public ExecuteEventRunnable (ObserverMethod delegate, Object event) { 
this.delegate = delegate; 
this.event = event; 


QOverride 
public void run() { 
delegate.notify (event); 


Simplesmente chamamos o observador original, representado pelo objeto 
delegate, dentro de um Runnable. Sabendo um pouco do funciona- 
mento de Threads dentro do Java, sabemos que basta fazer algo como new 
Thread (Runnable) .start () para executar o Runnable em uma nova 





Thread, realmente é bem simples, mas como estamos rodando nosso código dentro 
de um servidor, essa não é uma abordagem recomendada. 

Tradicionalmente, a utilização de múltiplas threads dentro do Java EE é bem di- 
ferente do seu uso no JavaSE. Enquanto em uma aplicação desktop podemos usar 
new Thread como citado, no Java EE a forma de fazer isso era disparar uma men- 
sagem JMS para que um Message-Driven Bean a processasse de forma assíncrona. 
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No Java EE 6 isso foi simplificado com a adição da anotação Asynchronous que 
já vimos. Isso facilitou muito o uso, mas como estamos construindo uma alternativa 
justamente a esse mecanismo, precisamos de outra alternativa. 

Felizmente, o Java EE 7 adicionou o uma nova especificação, a “Con- 
currency Utilities for Java EE” (JSR-236) [?]. Essa especificação simples- 
mente nos oferece uma API Java EE compatível com a API JavaSE disponí- 
vel desde o Java 5. Enquanto no SE essas funcionalidades estão no pacote 
java.util.concurrent, no EE 7, essa nova especificação definiu o pacote 
javax.enterprise.concurrent. De forma parecida, no JSE temos principal- 








mente as interfaces ExecutorService e ThreadFactory, já no JEE temos as 





respectivas interfaces ManagedExecutorService e ManagedThreadFactory 


Após esse breve entendimento do significado dessas interfaces, vejamos a im- 





plementação do método getExecutor (), que é onde buscaremos as instâncias 
corretas. 


private ExecutorService getExecutor() 1 
if (executor != null) { 
return executor; 


try É 
Context ctx = new InitialContext (); 
executor = (ManagedExecutorService) 
ctx.lookup("java:comp/env/concurrent /ManagedExecutorService"); 
} catch (Exception e) { 
" 


logger.error("Erro ao buscar o 
+ " ManagedExecutorService (JSR 236)", e); 


logger .warn("Usando implementação simples " + 
" de newCachedThreadPool()'); 


executor = Executors.newCachedThreadPool(); 


return executor; 


Sempre buscaremos no contexto da aplicação uma instância gerenciada de 





ExecutorService, pois ela certamente estará integrada ao pool de Threads que 
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o servidor já possui, e não correremos o risco de interferir negativamente no ciclo de 
vida da aplicação e do servidor, evitando qualquer vazamento de memória ou coisas 
do gênero. Para conseguirmos recuperar esse objeto, adicionamos no web.xml da 
aplicação o seguinte conteúdo. 


<resource-env-ref> 
<resource-env-ref -name> 
concurrent /ManagedExecutorService 
</resource-env-ref -name> 
<resource-env-ref-type> 
javax.enterprise.concurrent.ManagedExecutorService 
</resource-env-ref-type> 
</resource-env-ref> 


Precisamos dessa configuração porque não existe um caminho padrão defi- 





nido para recuperarmos o ManagedExecutorService. O mesmo vale para o 


ManagedThreadFactory 


Para terminar nossa análise, precisamos ter bastante atenção no con- 





teúdo do catch no método getExecutor(). Caso não consiga- 





mos recuperar o | ManagedExecutorService, utilizaremos o método 





Executors.newCachedThreadPool (), porém registraremos um aviso no 
log para que isso seja averiguado. Pode ser que a configuração do nome JNDI 
não esteja correta, mas pode ser que não esteja disponível uma implementação de 





ExecutorService. Apesar dessa implementação ser parte do Java FE, é bem 
possível que em breve conseguiremos utilizá-la dentro de servlet containers. 

Espero que neste capítulo tenha ficado claro a vantagem de termos extensões 
portáveis, mas que também tenha servidor para indicar um caminho quando essa 
não for uma possibilidade, no caso das extensões não portáveis. Como acabamos de 
falar de servlet containers, passaremos agora para o último capítulo, onde veremos 
a utilização de CDI em ambientes não Java EE, dentre eles o servlet container. 


CAPÍTULO 10 


Executando CDI em diferentes 
ambientes 


A CDI é uma especificação pensada para o Java EE, mas como já adiantamos em di- 
versos momentos, é possível executá-lo fora desse ambiente. Nesse capítulo veremos 
como executar CDI em servlet containers, a partir de uma classe main e também em 
testes de integração. 

Nosso foco nesses exemplos vai deixar de ser a funcionalidade da CDI, pois já 
vimos bastante sobre isso durante todo o livro. Agora iremos focar na configuração 
necessária para executar nesse ambientes. Essas são configurações específicas para 
o Weld, implementação de referência da CDI, pois a especificação não aborda esses 
ambientes. 
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10.1 EXECUTANDO CDI EM SERVLET CONTAINERS 


Ao executar uma aplicação dentro de um servlet container, temos que lembrar das 
diversas funcionalidades que não estarão disponíveis, como controle automático de 
transações, eventos assíncronos, mensageria, dentre outras. Porém isso muitas vezes 
não é um problema, uma vez que já sabemos como implementar, com pouco esforço, 
essas funcionalidades, seja via extensão ou simplesmente adicionando um jar com 
as funcionalidades implementadas. 

Nessa seção iremos utilizar como referência o tomcat, mas na documentação do 
Weld encontramos como proceder a configuração para executar no jetty também. 
Como esses servidores não tem a obrigação de prover os serviços da CDI, teremos 
que, pela primeira vez, fazer o download do Weld. Obviamente é possível utilizar 
gerenciadores de dependência como maven ou ivy, mas por termos que adicionar 
basicamente dois jars, procederemos da forma tradicional mesmo. 

O download do Weld pode ser feito no seguinte endereço: http://www. 
seamframework.org/Weld/Downloads. Após descompactar o arquivo baixado, 
precisamos de apenas dois jars que podem ser encontrados dentro da pasta 
artifacts, são eles cdi-api.jar e weld-servlet. jar. Basta criarmos 
um projeto web na IDE da nossa preferência e colocar esses jars dentro da pasta 
WEB-INF/1ib. Precisamos lembrar também, assim como já fazíamos nos proje- 


tos Java EE, é de colocar o arquivo beans.xm1, mesmo vazio, dentro da pasta 





WEB-INF. 

A partir desse momento já estamos com o setup básico feito, temos então que 
partir para as configurações propriamente ditas. Não se preocupe com a possibi- 
lidade de esquecer algum detalhe, pois você pode verificar se seu projeto possui 
todas as configurações comparando-o com o projeto disponível no github: https: 
/lgithub.com/gscordeiro/cdi-tomcat. 

Um objeto muito importante para a CDI é o BeanManager. Esse objeto é sem- 
pre necessário e alcançável via JNDI em ambiente Java EE. Porém como estamos 
usando um servlet container, vamos precisar fazer uma configuração para adicionar 
esse objeto dentro do contexto JNDI da aplicação. No tomcat, essa configuração é 





feita dentro do arquivo META-INF/context . xml, cujo conteúdo vemos a seguir. 


<Context> 
<Resource name="BeanManager" auth="Container" 
type="javax.enterprise.inject.spi.BeanManager" 
factory="org.jboss.weld.resources.Manager0bjectFactory" /> 
</Context> 
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Para completar a configuração do BeanManager, precisamos adicionar no 
web. xml uma entrada que cria uma referência com o nome "BeanManager" para 





otipo javax.enterprise.inject.spi.BeanManager. 


<resource-env-ref> 
<resource-env-ref -name>BeanManager</resource-env-ref -name> 
<resource-env-ref-type> 
javax.enterprise.inject.spi.BeanManager 
</resource-env-ref-type> 
</resource-env-ref> 


Ao atribuirmos esse nome ao BeanManager, ele fica disponível no contexto 
JNDI com o nome "java:comp/env/BeanManager". Nós não precisamos usar 
diretamente esse nome, mas o módulo servlet do Weld vai precisar. 

Agora que o JNDI está pronto, precisamos colocar mais uma configuração no 
web. xml, que é o Listener do Weld que irá subir o contexto CDI e também interagir 
com as requisições. 


<listener> 
<listener-class> 
org. jboss.weld.environment.servlet.Listener 
</listener-class> 
</listener> 


Agora sim terminamos, nossa aplicação está pronta para utilizar as funcionali- 
dades da CDI. Apenas para testarmos, vamos criar uma servlet que faz a injeção de 
uma CalculadoraSalarios. Apesar de continuarmos no mesmo exemplo da 
aplicação Java EE, aqui iremos ter implementações bem mais simples, pois o intuito 
é apenas testar o setup do ambiente. 


OWebServlet ("/calculadoraSalario") 
public class CalculadoraSalarioServlet extends HttpServlet { 


OInject 
private CalculadoraSalarios calculadoraSalarios; 


QOverride 

protected void doPost (HttpServletRequest req, 
HttpServletResponse resp) 
throws ServletException, IOException { 
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Funcionario funcionario = new Funcionario( 
req.getParameter ("funcionario"), 
Double. parseDouble(reqg.getParameter ("salario"))); 


double salario = 
calculadoraSalarios.calculaSalario(funcionario); 


System.out.printf ("Salário do(a) hs é %.2f", 
funcionario.getNome(), 
salario); 


O uso do System.out é apenas para simplificar o exemplo, no projeto do 
github temos um simples formulário de entrada de dados e uma página que exibe o 
resultado. 

A implementação da CalculadoraSalarios aqui nesse projeto é bem mais 
simples, apenas adiciona 10% (dez porcento) ao salário base do funcionário. 


public class CalculadoraSalarios { 


OInject 
private Event<Funcionario> calculoSalarioEvent; 


public double calculaSalario (Funcionario funcionario)( 
calculoSalarioEvent .fire(funcionario); 
return funcionario.getSalarioBase() * 1.1; 


Temos também o lançamento de um evento simples, que serve para indicar que o 
salário do funcionário foi calculado. Como já vimos esse conteúdo, aqui não utiliza- 
mos qualquer qualificador; queremos apenas ver que os eventos também funcionam 
no servlet container como no application server. 


Por fim temos o observador do evento, nos mesmos moldes que já vimos antes. 


public class ObservadorCalculadora { 


public void escutaCalculoSalario(O0bserves Funcionario funcionario)f 
" 


System.out.printf ("0 salário do(a) hs 
+ " acabou de ser calculadon", funcionario.getNome()); 
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Essa seção foi relativamente curta pois já vimos todo o conteúdo, e também por- 
que a configuração em si também não é extensa. Então se em nossa organização 
utilizamos servlet containers em vez de servidores de aplicação Java EE, não precisa- 
mos abrir mão das grandes vantagens da CDI. Tomcat e Jetty diferem bem pouco em 
sua configuração. Como o arquivo web. xm1 faz parte da especificação de servlets, a 





única mudança será no arquivo META-INF /context . xml do tomcat, que no jetty 





se chama WEB-INF/jetty-env.xm1 e tem o seguinte conteúdo. 


<!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure//EN" 
"nttp://uuw.eclipse.org/jetty/configure. dtd"> 


<Configure id="webAppCtx" 
class="org.eclipse. jetty.webapp.WebAppContext"> 
<New id="BeanManager" class="org.eclipse. jetty.plus.jndi.Resource"> 
<Arg> <Ref id="webAppCtx"/> </Arg> 
<Arg>BeanManager</Arg> 
<Arg> 
<New class="javax.naming.Reference"> 
<Arg>javax. enterprise. inject.spi.BeanManager</Arg> 
<Arg>org. jboss.weld. resources. Manager0bjectFactory</Arg> 


<Arg/> 
</New> 
</Arg> 
</New> 
</Configure> 


10.2 EXECUTANDO CDI A PARTIR DE UMA CLASSE MAIN 


Assim como precisamos fazer na seção anterior, precisamos baixar o Weld na pá- 
gina do projeto: http://www.seamframework.org/Weld/Downloads. Já tendo os 
jars baixados, precisamos criar um novo projeto Java simples e adicionar os jars 
cdi-api.jar e weld-se. jar no seu classpath. Você também pode verificar 
seu projeto comparando com o disponível no github: https://github.com/gscordeiro/ 
cdi-desktop. 

Não será necessário criar configurações para usar Weld dentro da nossa main, 
basta fazermos a inicialização do contexto manualmente. 
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public class CalculadoraMain ( 
public static void main(Stringl[] args) { 


Weld weld = new Weld(); 
WeldContainer container = weld.initialize(); 


CalculadoraSalarios calculadoraSalarios = container. instance() 
. select (CalculadoraSalarios.class) .get(); 


Funcionario funcionario = new Funcionario("Fulano", 5000.0); 


double salario = 
calculadoraSalarios.calculaSalario (funcionario); 


System.out.printf ("Salário calculado do hs é %.2f\n", 
funcionario.getNome(), salario); 


weld.shutdown (D ; 


Uma limitação do Weld em aplicação JSE está nos escopos disponíveis: aplicação, 
dependente e singleton, já que não existe requisição e sessão fora de um servidor. 

Apesar de na main não termos usado @Inject, utilizamos uma forma de loo- 
kup programático. Mas a injeção continua funcionando, basta vermos o código da 


CalculadoraSalarios. 


public class CalculadoraSalarios { 


OInject 
private Event<Funcionario> calculoSalarioEvent; 


public double calculaSalario (Funcionario funcionario)( 
calculoSalarioEvent .fire(funcionario); 
return funcionario.getSalarioBase() * 1.1; 


É exatamente o mesmo código que utilizamos na aplicação cdi-tomcat. 
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Podemos também fugir da subida manual do contexto do Weld, bas- 
tando para isso usar uma classe main disponível dentro do weld-se.jar: 
org.jboss.weld.environment.se.StartMain. Ao subir o contexto, o Weld 
lança o evento ContainerInitialized,e nossa “falsa main” observa esse evento. 


import org.jboss.weld.environment.se.bindings.Parameters; 
import org.jboss.weld.environment.se.events.ContainerInitialized; 


OSingleton 
public class CalculadoraFalsaMain { 


OInject 
private CalculadoraSalarios calculadoraSalarios; 


public void printHello(Q0bserves ContainerInitialized event, 
OParameters List<String> parameters) { 


Funcionario funcionario = new Funcionario("Fulano", 6000.0); 


double salario = 
calculadoraSalarios.calculaSalario(funcionario); 


System.out.printf ("Salário calculado do hs é %.2f\n", 
funcionario.getNome(), salario); 


Agora sim, nossa “falsa main” consegue trabalhar com injeção da 
CalculadoraSalarios. Além disso, usamos o qualificador GParameters 
para solicitar ao container a injeção dos parâmetros da main original; o famoso 
String[] args. 

Assim como no projeto cdi-tomcat, os eventos continuam funcionando, as- 
sim como interceptadores, decoradores e as outras funcionalidades da CDI. 


10.3 E COMO TESTAR UMA APLICAÇÃO CDI? 


Já no início do livro mostramos como a CDI nos deixa livres para construir projetos 
de classes testáveis. Isso para testes de unidade resolve a questão, mas precismos 
também lidar com testes de integração e de sistema. Nosso foco nessa seção estará 
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nos testes de integração, pois é onde a CDI atua, fazendo a injeção das dependências, 
decorando e interceptando as invocações, além é claro de eventos e outros tópicos 
que já vimos. 

Atualmente, a ferramenta de automação de testes de integração mais utilizada no 
Java EE é o Arquillian (http://arquillian.org/) . Ele nos permite, de dentro do nosso 
caso de teste, subir um contexto de CDI para que consigamos executar nosso teste 
junto com injeção de dependência, controle de transações, e tudo mais que se fizer 
necessário para nossos testes reproduzirem situações reais da aplicação. 


Um pouco de Arquillian 


Para construir nossos testes de integração com Arquillian, precisamos entender 
como eles funcionarão com a ferramenta. Para isso vamos fazer um paralelo com o 
processo manual de construção da aplicação, deploy e testes. 

Quando estamos desenvolvendo nossa aplicação, colocamos todas classes e ar- 
quivos de configuração necessários nos locais corretos, em seguida fazemos o em- 
pacotamento da aplicação. Esse empacotamento pode ser um arquivo jar, war ou 
ear. Muitas vezes a IDE esconde esse processo de nós, fazendo o empacotamento 
e o deploy e a inicialização do servidor de forma automática quando executamos a 
ação “Executar”. Porém temos que ter em mente que todos esses passos precisam 
acontecer para nossa aplicação possa ser testada. 

Para fazem o empacotamento da aplicação a ser testada, utilizamos o Shrink- 
Wrap (http://www.jboss.org/shrinkwrap) , que é uma ferramenta de criação progra- 
mática de pacotes java. Veremos na prática como utilizar essa ferramenta, que nos 
oferece uma API fluente muito simples de usar. 

Após o empacotamento, precisamos fazer o deploy desse pacote. Aqui entra um 
outro aspecto muito interessante do Arquillian, que são os container adapters. Te- 
mos basicamente três tipos de adapters: Embedded, Managed e Remote. Além disso 
temos adapters para diferentes containers de cada um desses tipos. 

Por exemplo, analisando GlassFish e JBoss, vemos que temos os três tipos de 
adaptador de GlassFish 3.1 (mas que executa também o GlassFish 4); já para o JBoss 
7.1 temos apenas os tipos Managed e Remote. 


A diferenciação entre esses tipos é simples: 


e Embedded: Nesse tipo de adaptador, o Arquillian sobe uma instância do con- 
tainer, seja ele GlassFish, JBoss, outro servidor ou até mesmo um container 
só com o Weld em execução, tudo isso de dentro do próprio teste. Aqui não 
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é necessário baixar o servidor e instalar (descompactar) na nossa máquina, 
podemos deixar o Arquillian fazer todo o trabalho. Por isso esse tipo de adap- 
tador é chamado “embarcado”, pois ele sobe de dentro do próprio teste. 


* Managed: Nesse tipo de adaptador, o Arquillian uma uma instalação do con- 
tainer existente externamente, mas é ele quem gerencia a subida e a descida 
do container. 


e Remote: Já neste último tipo de adaptador, o Arquillian faz uso de uma ins- 
tância já existente e em execução de container. Ou seja, o servidor já deve estar 
rodando para que o deploy do nosso pacote seja realizado. 


Em todos esses tipos de adaptadores, o Arquillian faz o deploy, executa os testes, 
e depois faz o undeploy do pacote. Nos dois primeiros tipos, no before class dos 
nossos testes o Arquillian também sobe o container eno after class baixa esse 
container de forma automática. Já o tipo Remote é o mais comum quando tempos 
um servidor voltado para os testes, ou quando temos muitos testes e gostaríamos de 
subir o servidor uma única vez. Nesse caso podemos fazer um script que suba e desça 
o servidor antes e depois dos testes. No nosso exemplo faremos uso do adaptador 
GlassFish Embedded. 


Configurando as dependências 


A montagem do ambiente Arquillian não é muito simples, envolve muitas depen- 
dências, assim, é difícil configurá-lo sem o auxílio de ferramentas como o maven ou o 
ivy. Por ser a forma mais comum, e consequentemente mais fácil de encontrar exem- 
plos, utilizaremos o maven. Como o arquivo pom.xml costuma ver extenso, vere- 
mos apenas partes dele aqui, mas seu conteúdo completo está disponível no github: 
https://github.com/gscordeiro/cdi-arquillian. 

Criamos um novo projeto com suporte ao maven para colocar nossos testes. Essa 
separação tem somente o intuito de deixar o projeto inicial mais leve, senão enquanto 
estivéssemos adicionando pequenas funcionalidades e executando o projeto no ser- 
vidor, teríamos o maven rodando toda a bateria de testes, subindo e descendo o con- 
texto do glassfish toda hora, deixando o processo todo mais lento. Obviamente isso é 
configurável, mas além de simplificar o processo como um todo, o projeto apartado 
serve como uma referência rápida para você que já tem seus projetos CDI e deseja 
adicionar somente os testes. Ou seja, a separação é apenas didática, em um projeto 
real os testes ficam junto com seu projeto. 
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Para mantermos o foco, vamos ignorar, por hora, configurações comuns do pro- 
jeto no maven, como dependências de Java EE e JUnit. 


<dependencyManagement > 
<dependencies> 
<dependency> 
<groupId>org. jboss.arquillian</groupld> 
<artifactId>arquillian-bom</artifactId> 
<version>1.1.1.Final</version> 
<scope>import</scope> 
<type>pom</type> 
</dependency> 
</dependencies> 
</dependencyManagement> 


<dependencies> 

<dependency> 
<groupld>org.glassfish.main.extras</groupld> 
<artifactId>glassfish-embedded-all</artifactId> 
<version>4.0</version> 
<scope>provided</scope> 

</dependency> 

<dependency> 
<groupld>org. jboss.arquillian.container</groupld> 
<artifactId>arquillian-glassfish-embedded-3.1</artifactId> 
<version>1.0.0.CR4</version> 
<scope>test</scope> 

</dependency> 

<dependency> 
<groupld>org. jboss.arquillian. junit</groupld> 
<artifactId>arquillian-junit-container</artifactId> 
<version>1.1.0.Final</version> 
<scope>test</scope> 

</dependency> 

</dependencies> 


Além das dependências básicas, como Java EE e JUnit, também deixaremos para 
logo mais a configuração de persistência do arquillian. Agora vamos ver como rea- 
lizar um teste simples usando o arquillian. 


ORunWith (Arquillian.class) 
public class CalculadoraSalariosTest 1 
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CDeployment 
public static JavaArchive createDeployment() { 


return ShrinkWrap.create(JavaArchive.class) 
.addClass (Funcionario.class) 
.addClass (CalculadoraSalarios.class) 
.addClass (CalculadoraSalariosDezPorcento.class) 
. addAsManifestResource (EmptyAsset. INSTANCE, "beans.xml"); 


Aqui podemos ver a estrutura básica da classe de testes. Usamos a anotação 
Gorg. junit.runner.RunWith do JUnit e passamos ao Arquillian o gerencia- 
mento do ciclo de vida do teste, permitindo à ferramenta subir e descer o container 
quando necessário. 

O empacotamento do que será testado é feito através de um método está- 
tico que devolve o pacote montado programaticamente. No nosso exemplo é um 
org. jboss.shrinkwrap.api.spec.JavaArchive. Por mais que nossa apli- 
cação seja web, como vamos testar apenas a calculadora, não havendo qualquer tela, 
podemos fazer nesse momento um jar em vez de um war. 

Para montar nosso pacote vamos adicionando as classes, e também os recursos 


que necessitarmos. Perceba como criamos um arquivo chamado "beans.xml", 








em branco ( EmptyAsset.INSTANCE), e dentro do “manifest resource” ( 
addAsManifestResource). Esse último método é muito interessante pois sabe 
exatamente o local onde o arquivo deve ser colocado. Se estivéssemos criando um 





WarArchive teríamos ainda um método addAsWebInfResource para colocar o 
recurso também no local correto. Muito mais simples do que ficarmos nos preocu- 
pando com as pastas e arquivos "build.xml" do Ant. 

Mais um fator importante a notarmos é que criamos sempre pacotes somente 
com o necessário para executar o teste atual. Então se nossa aplicação é grande, 
cheia de EJBs, páginas web, e diversas bibliotecas, a aplicação demora mais para subir. 
Mas criando um pacote como esse do teste que tem apenas três classes, certamente 
o tempo de subir e descer o pacote será incomparavelmente menor. 

Vamos agora retornar à classe CalculadoraSalariosTest, onde vamos tes- 
tar nossa calculadora. 
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CDeployment 
public static JavaArchive createDeploymentO 1... 5 


OInject 
private CalculadoraSalarios calculadoraSalarios; 


OTest 


public void deveAumentarSalarioBaseEmDezPorcento (1 


Funcionario funcionario = 
new Funcionario("Fulano", 4000.0, Escolaridade.MEDIO) ; 


double salario = calculadoraSalarios.calculaSalario(funcionario); 


assertEquals(4400.0, salario, 0.001); 


Essa classe Funcionario e a classe CalculadoraSalarios são 
versões simplificadas das classes que já vimos. Isso novamente apenas 
para deixar o projeto cdi-arquillian mais simples. A implementação 
CalculadoraSalariosDezPorcento, por exemplo, apenas adiciona 10% (dez 
porcento) ao valor do salário base do Funcionario. 


Testando ambiguidade 


Podemos fazer mais um teste interessante para verificarmos a ambiguidade de 
dependências. 


@RunWith (Arquillian.class) 
public class AmbiguidadeTest { 


CDeployment 
public static JavaArchive createDeployment() { 
return ShrinkWrap.create(JavaArchive.class) 
.addClass (CalculadoraSalarios.class) 
. addClass (CalculadoraSalariosDezPorcento.class) 
. addClass (CalculadoraSalariosVintePorcento.class) 
. addAsManifestResource (EmptyAsset. INSTANCE, "beans.xml"); 


Nesse exemplo, montamos um pacote com a interface CalculadoraSalarios 
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e suas duas implementações. Agora vamos injetar uma instância dessa interface uti- 
lizando javax.enterprise.inject.Instance, e em seguida vamos verificar 





a ambiguidade e depois resolvê-la. 


CDeployment 
public static JavaArchive createDeployment() 1... 5 


OInject 
private Instance<CalculadoraSalarios> calculadoraSalarios; 


OTest 
public void deveApresentarAmbiguidade()( 
assertTrue(calculadoraSalarios. isAmbiguous()); 


OTest 
public void naoDeveApresentarAmbiguidade ()( 
Instance<? extends CalculadoraSalarios> calculadoraEspecifica = 
calculadoraSalarios.select( 
CalculadoraSalariosVintePorcento.class); 


assertFalse(calculadoraEspecifica. isAmbiguous()); 


Até aqui, poderíamos ter utilizado apenas o adaptador do próprio Weld no lugar 
de termos utilizado o do GlassFish. Porém agora iremos explorar exemplos envol- 


vendo persistência, e nesse caso precisamos de uma solução mais completa. 


10.4 DESENVOLVENDO TESTES DE INTEGRAÇÃO COM PER- 
SISTÊNCIA 


Como resultado da seção anterior, já temos o ambiente de testes funcionando com 
o arquillian. Agora vamos expandir nosso ambiente para termos suporte à extensão 
de persistência. Precisamos para isso adicionar o seguinte trecho de código na seção 


<dependencies> do pom.xml. 


<dependencies> 
<dependency> 
<groupld>org.jboss.arquillian.extension</groupld> 
<artifactId>arquillian-persistence-impl</artifactId> 
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<version>1.0.0.Alpha5</version> 
<scope>test</scope> 
</dependency> 
</dependencies> 


Agora conseguimos facilmente controlar transação dentro dos testes, e conse- 
guimos também utilizar o DBUnit (http://dbunit.sourceforge.net) . É muita possibi- 
lidade junta, mas vejamos como a utilização é simples. Para iniciar, faremos um teste 
bem simples de inserção de funcionários no banco de dados. Novamente veremos o 
código em partes para irmos analisando cada parte. 


ORunWith (Arquillian.class) 
public class FuncionarioPersistenceTest { 


CDeployment 
public static JavaArchive createDeployment() { 


return ShrinkWrap.create(JavaArchive.class) 
.addClass (Funcionario.class) 
. addAsManifestResource( 
new File("src/test/resources/META-INF/persistence-teste.xml"), 
"persistence.xml") 
. addAsManifestResource (EmptyAsset. INSTANCE, "beans.xml"); 


Agora nosso pacote tem somente uma classe, a entidade Funcionario, 
e temos mais dois recursos: o primeiro é o arquivo persistence.xml e 
o outro é o beans.xml. Já vimos que este último será um arquivo vazio, 
mas o persistence é bastante interessante, pois criamos um arquivo chamado 





persistence-teste.xml, com uma configuração de banco de dados específica 
para o ambiente de testes, e ao adicioná-lo no pacote mudamos seu nome para 
persistence.xml, que é o esperado pelo container. 

Nesse arquivo, configuramos o mecanismo de persistência para construir o 
banco quando o contexto subir e para apagar o banco quando os testes termina- 
rem. Dessa forma, a cada teste o banco será reconstruído, então não precisamos nos 
preocupar em apagar os dados manualmente entre uma execução e outra do teste. 

Nesse momento temos um pacote CDI que possui a funcionalidade de persis- 
tência ativada. E agora podemos novamente encarar o próprio teste como se fosse 
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um bean gerenciado pela CDI, injetando inclusive o EntityManager. 


GDeployment 
public static JavaArchive createDeployment() 1... 5 
OPersistenceContext (unitName = "livroCdiPU") 


EntityManager em; 


OTest 
OTransactional 
public void deveInserir2Funcionarios() { 


TypedQuery<Funcionario> query = 
em.createQuery ("select f from Funcionario f", Funcionario.class); 


assertEquals(0, query.getResultList () .size()); 


Funcionario funcionariol = 

new Funcionario("Xico!", 2000.0, Escolaridade .FUNDAMENTAL) ; 
Funcionario funcionario2 = 

new Funcionario("Maria", 4000.0, Escolaridade.MEDIO) ; 


assertEquals (null, funcionariol.getId()); 
assertEquals (null, funcionario2.getId()); 


em.persist (funcionariol); 
em.persist (funcionario2); 


assertEquals (Integer. value0f (1), funcionariol.getId()); 
assertEquals (Integer. value0f (2), funcionario2.getId()); 


assertEquals(2, query.getResultList().size()); 


Esse teste nos mostra como proceder no teste de persistência. 
Com a extensão de persistência do arquillian, temos acesso à anotação 
Gorg.jboss.arquillian.persistence.Transactional. Anotando o 
teste com ela, este fica transacional, nos permitindo salvar objetos no banco como 
se estivéssemos dentro de um EJB. Uma outra prática é anotar o método de testes, 
ou toda a classe, com ETransactional (TransactionMode.ROLLBACK), para 
que os dados não sejam persistidos, gerando sempre um rollback na transação atual. 
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Assim os diversos métodos não influenciam um no outro. 


O uso do DBUnit de forma muito simples 


Outra ferramenta que nos auxilia a criar testes envolvendo a camada de persis- 
tência, é o DBUnit. Como já adicionamos a extensão de persistência do arquillian, o 
DBUnit já está disponível. 

O DBUnit trabalha basicamente montando uma massa de dados antes de cada 
teste, e ao final verifica se os dados ficaram como o esperado. Ele trabalha no nível 
de banco de dados, e não nos objetos, o que nos permite inclusive testar possíveis 
procedures existentes no projeto. 


ORunWith (Arquillian.class) 
public class FuncionarioDBUnitTest ( 


CDeployment 
public static JavaArchive createDeployment() {...} 


OPersistenceContext (unitName = "livroCdiPU") 
EntityManager em; 


OTest 

QUsingDataSet ("funcionarios.x1s') 

CShouldMatchDataSet ("funcionarios-expected.x1s") 

public void deveDari0PorcentoAumentoAosFuncionariosNivelSuperior() { 


List<Funcionario> funcionarios = 
em.createQuery ("select f from Funcionario f " 


+ "where f.escolaridade = :escolaridade", Funcionario.class) 
.setParameter("escolaridade", Escolaridade .SUPERIOR) 
.getResultList(); 


for (Funcionario funcionario : funcionarios){ 
double salarioAtual = funcionario.getSalarioBase(); 
funcionario.setSalarioBase(salarioAtual * 1.1); 
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Nesse outro teste, o método createDeployment () é exatamente igual ao do 
exemplo anterior. O que podemos notar de diferença é a presença das duas anotações 
que faz uso referência ao DBUnit: GUsingDataSet e EShouldMatchDataset. 

No DBUnit, os datasets podem ser vários tipos de arquivos, como XML, YML, 
e no nosso exemplo utilizamos planilhas XLS, pois elas se parecem bem com as ta- 
belas que desejamos representar. Para utilizar uma planilha, basta que cada planilha 
dentro do arquivo tenha o mesmo nome de cada tabela, e cada coluna da planilha 
tem que ter o mesmo nome das colunas do banco. 

Como essa ferramenta trabalha no nível de tabelas, não temos que analisar o 
modelo OO, e sim o relacional. Precisamos reproduzir nas planilhas o modelo rela- 
cional, não o OO, isso é importante. Para ficar bem claro, vamos analisar a estrutura 
dessa classe Funcionario, que é mais simples do que a tínhamos visto até antes de 


inciarmos esses testes. 


public enum Escolaridade 1 
FUNDAMENTAL, MEDIO, SUPERIOR 


CEntity 
public class Funcionario implements Serializable { 


@Id @GeneratedValue 

private Integer id; 

private String nome; 

private double salarioBase; 
private Escolaridade escolaridade; 


//getters e setters 


Agora vejamos as duas planilhas, a que possui os dados iniciais, e a que possui 
os dados esperados. 
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É funcionarios.xIs 





salarioBase escolaridade 
2000 


| 





Figura 10.1: Dados iniciais do teste 


O próprio DBUnit apaga todos os dados da tabela e deixa exatamente com os 
dados esperados. 
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Figura 10.2: Dados esperados ao final do teste 


Após o teste é feita a verificação se os dados ficaram de acordo com o esperado. 
Se não estiver o teste falha, não é necessário assert. 

Como nosso teste é feito com base na escolaridade do funcionário, e esse dado 
é um Enum, na tabela, por padrão, esse dado vira um inteiro. Como podemos vera, 
temos dois funcionários com nível superior: Ana, com salário base de R$ 4.000,00; e 
Antônio com salário de R$ 5.000,00. Na planilha com os dados esperados alteramos 
apenas os valores dos salários desses funcionários, acrescentando 10% (dez porcento) 
como pede o teste. 

A partir desse ponto, basta implementar os demais testes de negócio da nossa 
aplicação, pois os mecanismos já estão funcionando. Espero que esse último capítulo 
tenha servido também como um pequeno tutorial de Arquillian, pois além de testar 
as funcionalidades da CDI, essa ferramenta auxilia muito nos testes com Java EE de 
modo geral. 

Assim como este último capítulo, espero que este livro tenha servido para auxi- 
liar no seu desenvolvimento profissional como um todo. A CDI é uma especificação 
muito interessante, e espero que seus estudos tanto em CDI como em Java EE conti- 
nuem evoluindo. O Java EE tem mudado bastante nas últimas versões, se tornando 
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cada vez mais simples de utilizar, mesmo assim acredito que este livro tenha contri- 
buído para deixar seu entendimento ainda mais simples. 
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